Redtail Posted October 26, 2002 Share Posted October 26, 2002 I am getting incorrect displays of the dob's prior to 1970 whats happening. Server OS: Linux 2.4.18-17.7.x Database: MySQL 3.23.49 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.26 PHP Version: 4.1.2 (Zend: 1.1.1) tep_snapshot-20021022.zip Link to comment Share on other sites More sharing options...
Ajeh Posted October 26, 2002 Share Posted October 26, 2002 That was fixed awhile ago. Have you added any add-ons that might be out of date and effecting the account files? Link to comment Share on other sites More sharing options...
Redtail Posted October 26, 2002 Author Share Posted October 26, 2002 The DOB is showing correctly in the database but not showing correct in the html output. I have installed many addons which have been posted into the contrib section in the last 2 to 3 months. I have checked then and dont see any that have changed any of the account or general.php files. Any futher ideas as to where to look to fix it would be appreciated. Link to comment Share on other sites More sharing options...
Ajeh Posted October 26, 2002 Share Posted October 26, 2002 Check in your General.php that you have this function: //// // Output a raw date string in the selected locale date format // $raw_date needs to be in this format: YYYY-MM-DD HH:MM:SS // NOTE: Includes a workaround for dates before 01/01/1970 that fail on windows servers function tep_date_short($raw_date) { if ( ($raw_date == '0000-00-00 00:00:00') || ($raw_date == '') ) return false; $year = substr($raw_date, 0, 4); $month = (int)substr($raw_date, 5, 2); $day = (int)substr($raw_date, 8, 2); $hour = (int)substr($raw_date, 11, 2); $minute = (int)substr($raw_date, 14, 2); $second = (int)substr($raw_date, 17, 2); if (ereg('WIN', PHP_OS) && $year <= 1970) { return ereg_replace('2037' . '$', $year, date(DATE_FORMAT, mktime($hour, $minute, $second, $month, $day, 2037))); } else { return date(DATE_FORMAT, mktime($hour, $minute, $second, $month, $day, $year)); } } Link to comment Share on other sites More sharing options...
Redtail Posted October 26, 2002 Author Share Posted October 26, 2002 Yes that is in there and is correct. This dosent make any sense I have searched the forums for any help and all the info I can find points this problem to a win32 server problem not a linux server problem. Link to comment Share on other sites More sharing options...
Redtail Posted October 27, 2002 Author Share Posted October 27, 2002 I just did a full new install of the store and have the same dob problem. No changes or addons were done. Server OS: Linux 2.4.18-17.7.x Database: MySQL 3.23.49 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.26 PHP Version: 4.1.2 (Zend: 1.1.1) tep_snapshot-20021022.zip Link to comment Share on other sites More sharing options...
Ajeh Posted October 27, 2002 Share Posted October 27, 2002 I loaded Oct 16 ... it worked fine and Oct 25 and it works fine. Fresh installs and all. DOB works in both Admin and Customer on the display. Link to comment Share on other sites More sharing options...
Redtail Posted October 27, 2002 Author Share Posted October 27, 2002 Thank you very much for your help. I guess the problem must lie in my server somewhere. Time to get the admins involved to see whats happing. After some further checking I recall that all did work correctly before they did some updates to the server now to try and figure out where and what changes affected the date and time. I kinda wonder if it was changes to: linux, php, or mysql Thanks again Linda for all your help. Link to comment Share on other sites More sharing options...
Ajeh Posted October 27, 2002 Share Posted October 27, 2002 You might check which version of php you are running now. Link to comment Share on other sites More sharing options...
Redtail Posted October 27, 2002 Author Share Posted October 27, 2002 Server OS: Linux redhat 7.3 Database: MySQL 3.23.49 PHP Version: 4.1.2 Link to comment Share on other sites More sharing options...
Ajeh Posted October 27, 2002 Share Posted October 27, 2002 Operating System Linux Mysql Version 3.23.53a PHP Version 4.2.2 I am not sure if this is making a difference or not ... Techie types want to field this :D ? Link to comment Share on other sites More sharing options...
Redtail Posted October 29, 2002 Author Share Posted October 29, 2002 I found this at the php.net site http://bugs.php.net/bug.php?id=20048 [23 Oct 2:23pm] glibc-2.2.5-34 and greater has been changed to return -1 for dates < 1970. This used to work. The problem exists with RedHat 7.3 and 8.0 echo (mktime(0, 0, 0, 1, 1, 1960)); // prints -1 [23 Oct 2:26pm] glibc-2.2.5-34 and greater has been changed to return -1 for dates < 1970. This used to work. The problem exists with RedHat 7.3 and 8.0 echo (mktime(0, 0, 0, 1, 1, 1960)); // prints -1 [23 Oct 3:18pm] [email protected] unix timestamp behavior for negative values is undefined it *may* map to pre-1970 dates but there is no guarantee whatsoever Pre 1970 dates might end up a problem for others as systems get upgraded. Link to comment Share on other sites More sharing options...
Impulse Posted October 29, 2002 Share Posted October 29, 2002 Same thing happens here. If I enter a DOB before 1970 it changes to 12/31/1969 Link to comment Share on other sites More sharing options...
Redtail Posted October 29, 2002 Author Share Posted October 29, 2002 As a followup take a look in bug reports #774 and #761 for further info. This could be a big problem to users of redhat that upgrade to 7.3 or 8.0 that use dates prior to 1970. Nice to know I'm not going crazy!!!!! :shock: Link to comment Share on other sites More sharing options...
scatcat Posted October 29, 2002 Share Posted October 29, 2002 Not trying to be flippent or anything, coz I can see this could be a big problem. But would it not be easier just to remove DOB from the registration process. I have been to loads of sites, and registered, and never been asked for DOB. To me it seems to be a very intrusive question just to be able to buy some goods from a shop. There is also a post somewhere else on here, where someone was looking for a way to remove this, becuase they had had compliants from customers about it. Just a thought. Link to comment Share on other sites More sharing options...
Redtail Posted October 29, 2002 Author Share Posted October 29, 2002 Yup it's easy to turn off. /catalog/includes/application_top.php / Control what fields of the customer table are used define('ACCOUNT_GENDER', 'true'); define('ACCOUNT_DOB', 'true'); <---- change this from true to false define('ACCOUNT_COMPANY', 'false'); define('ACCOUNT_SUBURB', 'false'); define('ACCOUNT_STATE', 'true'); In my store I use the DOB for birthday greeting specials. Just hope it dont effect anything else. Link to comment Share on other sites More sharing options...
Redtail Posted October 29, 2002 Author Share Posted October 29, 2002 I think I just founed a fix In catalog/includes/functions/general.php around line 545 admin/includes/functions/general.php around line 110 change this if (ereg('WIN', PHP_OS) && $year <= 1970) { return ereg_replace('2037' . '$', $year, date(DATE_FORMAT, mktime($hour, $minute, $second, $month, $day, 2037))); } else { to this if (ereg('', PHP_OS) && $year <= 1970) { return ereg_replace('2037' . '$', $year, date(DATE_FORMAT, mktime($hour, $minute, $second, $month, $day, 2037))); } else { That will give back the correct dates for systems running redhat 7.3 and I think 8.0 Link to comment Share on other sites More sharing options...
Sammy1001 Posted November 19, 2003 Share Posted November 19, 2003 Hi ! I fixed this problem like this: function tep_date_short_dob($raw_date) { if ( ($raw_date == '0000-00-00 00:00:00') || ($raw_date == '') ) return false; $year = substr($raw_date, 0, 4); $month = (int)substr($raw_date, 5, 2); $day = (int)substr($raw_date, 8, 2); $hour = (int)substr($raw_date, 11, 2); $minute = (int)substr($raw_date, 14, 2); $second = (int)substr($raw_date, 17, 2); $dob = $day.'/'.$month.'/'.$year; return $dob; } Sammy 1001 Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.