Posted by frankcarey on November 5, 2008 at 10:04pm
Jump to:
| Project: | UC Discounts |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
when creating a new discount, I wanted to make the discount permanent, so I chose the highest year.
This gave the error along the lines " End date cannot be earlier than the Start date"... the start date was the same except the year (i put it all the way to 2050).
Since that date should be like 40 years in the future, there is a bug somewhere. Same error on 2049, but when i brought it back down to 2010, it worked. ( I didn't investigate further)
Using UC 6.2.x (from CVS today)
Comments
#1
The cause is that PHP can't deal with higher number that the server processor can support.
For 32 bit processor, the limit is about 2038, so, as we use mktime() to convert year into timestamp, you can't select a higher date than 2038 on 32 bit processor.
You can find more informations here : http://fr.php.net/mktime
I changed the returned message to notice about that limit, will be committed.
#2
committed for 6.x branch
#3
Automatically closed -- issue fixed for two weeks with no activity.
#4
Please update the error message to say "18th January 2038" rather than just "2038" per http://drupal.org/node/324230 .
#5
Rather "17th January 2038" -- 18th is not accepted either.
#6
Unix-family operating systems (e.g., Linux) use a signed 32 bit integer to hold the "timestamp" value. This is the count of seconds since 1970-01-01 00:00:00 GMT, and is currently around 1.27E+09. Unix may end up facing its own "Y2K" problem as the year 2038 draws near. The general assumption seems to be that we'll all be running (at least) 64 bit systems by then, and the problem will be postponed until some time after the Cubs win the World Series (or the Sun goes Red Giant and swallows the Earth, whichever comes first). However, as the OP found out, people are actually using dates out in the far future that are starting to exceed 2038-01-17, and causing problems with integer overflow (wrapping around to a negative, pre-1970 date). As you will recall, Y2K problems started cropping up by the mid '90s as "future" dates were entered into various systems — they didn't wait until the clock actually rolled over.
I don't know what The Powers That Be in the Unix/Linux world (and probably Windows too) are planning to do about this. They might want to emulate 64 bit integers, even on 32 bit (or smaller) systems, while waiting for everyone to upgrade to 64 bit hardware. Of course, all that data stored as 32 bit timestamps in databases and elsewhere will have to be converted to 64 bit values. This promises to be as much fun as Y2K was! Perhaps with that in mind, they'll get an earlier start and it won't be so frantic this time around.