unix timestamp

pohopo

is it just me or is the unix timestamp limit of 2038 a glaring flaw in PHP? if the past is any indication of future then in 2038 you will still have PHP apps running which will be using the unix timestamp. and this seems to be the only option when you want to manipulate dates.

i am still pretty new at PHP so many I am missing something.

Sxooter

Seeing as how the problem is that unix time stamps are 32 bit, and 64 bit systems should be all but ubiquitous by 2038, and therefore 64 bit ints standard in most compilers as well, the only real danger is if someone writes code that relies on the 2038 rollover somehow.

My guess is that by the time 2038 rolls around, the problem will be gone. Since PHP programs are interpreted, simply updating the OS and PHP should be all the fix we need.

csn

Here's a library that uses floats (normally 64 bit) instead of 32 bit integers:
ADOdb Date Time Library

Sxooter

And of course, if your a database nut like me, you do all your date / time arithmetic in the database, and only show it in PHP. :-)

csn

Yep, I like the database date/time functions much better. I don't like PHP's. You have to split them up into arrays with mktime() and other stuff.

Sxooter

Plus if you have to deal with time zones, then things just get that much uglier in PHP.

LordShryku

I wouldn't call it a flaw of php specifically...
http://2038bug.com/

Shrike

If people are still using PHP in 2038 I will be seriously impressed.

Unix, of course, will still be around :p

pohopo

Well, it looks like in 2038 there will be strong demand for people that can code in old school code.

csn

Heh, like COBOL coders and Y2K.

planetsim

Id say this bug will be fixed up relatively soon or close to the date however Id say by the time 2038 comes most will be using 64bit so shouldnt be a problem until later on that is if they dont change it correctly.

devinemke

and when all computers are 64-bit we will have the same problem again on May 28th, 60056.

Weedpacket

Originally posted by devinemke
and when all computers are 64-bit we will have the same problem again on May 28th, 60056.

Where did you get that number? I thought we had about half a trillion years or so. Of course, by then the calendar would have needed serious overhauling anyway.

Sxooter

I think he was just being playful and tossed out a number.

My maths show that 2³¹ (we don't use the last but, it's for sign sigh...) /60 seconds /60 minutes /24 hours / 365 days equals 68 years. 1970 is the beginning of the epoch, so 1970+68=2038, the year the clocks overflow.

2^{63/60/60/24/365} = 292,471,208,677 years. That plus 1970 means we can go until the year 292,471,210,647 (approximately) until we run out of seconds in a 64 bit int, if we don't use the sign bit. Twice that if we do.

csn

The year of 60056: Windows-32 64-bit date and time will fail (was started from January 1, 1601).

According to this page.

Wow, check out some of the other stuff:

# The year of 2005: some really old versions of Unix (in other words, 16-bit BSD) will fail this year.

The year of 2009: the Federal Aviation Administration finally finishes its Year-2000 preparations (in the United States of America).

January 1, 2020: systems that are still using the year of 1920 as a pivot year will fail.

January 1, 2020: the Apple Macintosh (System 6.0.4 and greater) Date and Time Control Panel can no longer set the current date.

December 23, 2023: Sunday. This date signals the end of the world according to the Mayan calendar.

January 1, 2030: systems that are still using the year of 1930 as a pivot year will fail.

February 6, 2036: 232 seconds from January 1, 1900.

January 19, 2038: all Unix-based computer operating systems will fail because it will then be 231 seconds from January 1, 1970.

February 6, 2040: at the time of 06:28:16, old Apple Macintoshs' long word seconds from January 1, 1904 will overflow.

September 17, 2042: IBM's mainframe 370 time-of-day clock will overflow.

January 1, 2044: for MS-DOS, 26 years from 1980, setting the most significant bit (MS😎. Signed variables using this will return a negative date.

January 1, 2046: the Amiga computer's operating system date will fail.

June 8, 2046: Some Unix password aging fails. 642 weeks from the year of 1970.

December 31, 2049: Microsoft Project 95 reaches its date and time limit.

December 31, 2078: Microsoft Excel 7.0 reaches its date and time limit.

June 6, 2079: 216 days from January 1, 1900.

January 1, 2080: MS-DOS file dates, which are displayed with two-digit years, are now ambiguous.

January 1, 2100: Y2.1K, most current personal computer BIOSes run out of dates; the MS-DOS "DIR" command renders the file-date years 2100 through 2107 as "99".

February 7, 2106: for Unix operating systems, 232 seconds from January 1, 1970; date and time overflows at 06:28:16.

January 1, 2108: for MS-DOS, 27 years elapse from 1980. The file date and time will overflow.

November 28, 2738: the approximate day of A.D. 1 million.

November 28, 4338: the COBOL-85 integer day 1,000,000 exceeds the six-digit field 9999. HTTP caching fails.

January 1, 10000: Year-10,000 problem, four-digit years will fail.

January 1, 29602: Microsoft's Windows NT File System (NTFS) will fail.

The year of 29940: the new Apple Macintoshes' signed 64-bit time will fail (has been valid since 30,081 B.C.).

July 31, 31086: the internal Digital Equipment Corporation VMS date and time will fail at 02:48:05.47.

Weedpacket

Originally posted by Sxooter
My maths show that 2³¹ (we don't use the last but, it's for sign sigh...)

Well, we do for dates pre-1970 - as far back as 1900. It's Windows that ignores the sign bit....

LordShryku

Originally posted by csn
According to this page.

Wow, check out some of the other stuff:
***

January 1, 29602: Microsoft's Windows NT File System (NTFS) will fail.

***

Again? Geez...
Well, at least now I can plan for it.