It seems that Perl will soon be able to deal with dates past 2038. Can your programming language do this? (See 2038bug.com.)
Neither Ruby 1.8 nor 1.9 can handle it (the idiom is
Time.at(2 ** 35).to_s), but a recent JRuby can.
I think I’ll have to file a 1.9 bug, that should really be fixed.
How about your favorite programming language?
Contributions
Comment feed for ongoing:
From: Bill Mill (Feb 07 2008, at 17:23)
Python, unfortunately, does not.
[link]
From: Chris Emery (Feb 07 2008, at 22:21)
Python does in it's datetime module though.
[link]
From: Peter Krantz (Feb 08 2008, at 00:40)
I learned that the hard way when implementing a Ruby library that queried MS Exchange for calendar items. Some items will have an end date > 2038 if they are reoccurring with no stop date.
However, you can use DateTime in Ruby to deal with dates > 2038.
Many languages may be depending on the OS date/time limitations.
[link]
From: Paul Morriss (Feb 08 2008, at 02:35)
When 2000 rolled by I started thinking about the 2038 bug. Just because it's a long way away doesn't mean we shouldn't start fixing it now, I thought. On the other hand, I could generate a bit of money in my retirement by fixing it in various places if no-one else had.
[link]
From: Doug Winter (Feb 08 2008, at 04:41)
python is fine:
>>> import datetime
>>> d = datetime.datetime(3004,12,23)
>>> d
datetime.datetime(3004, 12, 23, 0, 0)
[link]
From: Stéphane Bortzmeyer (Feb 08 2008, at 05:06)
The Haskell environment ghc (version 6.6) seems broken as well on a 32 bits machine but works on 64 bits boxes
Pentium :
Prelude> let mytime = System.Time.TOD 2100000000 0
Prelude> System.Time.toCalendarTime mytime
CalendarTime {ctYear = 2036, ctMonth = July, ctDay = 18, ctHour = 15, ctMin = 20, ctSec = 0, ctPicosec = 0, ctWDay = Friday, ctYDay = 199, ctTZName = "CEST", ctTZ = 7200, ctIsDST = True}
Prelude> let mytime = System.Time.TOD 2200000000 0
Prelude> System.Time.toCalendarTime mytime
CalendarTime {ctYear = 1903, ctMonth = August, ctDay = 13, ctHour = 16, ctMin = 47, ctSec = 45, ctPicosec = 0, ctWDay = Thursday, ctYDay = 224, ctTZName = "PMT", ctTZ = 561, ctIsDST = False}
AMD Opteron :
Prelude> let mytime = System.Time.TOD 2100000000 0
Prelude>
Prelude> System.Time.toCalendarTime mytime
CalendarTime {ctYear = 2036, ctMonth = July, ctDay = 18, ctHour = 15, ctMin = 20, ctSec = 0, ctPicosec = 0, ctWDay = Friday, ctYDay = 199, ctTZName = "CEST", ctTZ = 7200, ctIsDST = True}
Prelude> let mytime = System.Time.TOD 2200000000 0
Prelude> System.Time.toCalendarTime mytime
CalendarTime {ctYear = 2039, ctMonth = September, ctDay = 19, ctHour = 1, ctMin = 6, ctSec = 40, ctPicosec = 0, ctWDay = Monday, ctYDay = 261, ctTZName = "CEST", ctTZ = 7200, ctIsDST = True}
On an UltraSparc, I get the bug as well, may be because ghc used blindly the local headers and there is a time_t definition which is 32bits?
[link]
From: David (Feb 08 2008, at 05:48)
More importantly, can my *database* handle dates outside that range? I just made a test table in MySQL 5 (running on a 32-bit OS), and it handled dates outside the 1901-2038 range correctly, including comparison operators in queries.
[link]
From: James Justin Harrell (Feb 08 2008, at 09:25)
Just to be pedantic, the issue here is libraries, not programming languages. Saying a programming language can't handle dates past 2038, just because its standard library can't, is like saying C++ can't handle XML, since its standard library doesn't handle XML.
[link]
From: Aristotle Pagaltzis (Feb 08 2008, at 13:32)
James Justin:
That’s certainly a distinction; but is it a difference?
[link]
From: Bob Aman (Feb 08 2008, at 14:15)
Yeah, I brought up this issue with regards to feeds a few years back. Very, very few feed readers were able to handle dates after 2038, my own included. I'd be very glad to hear that Ruby 1.9 finally addressed the issue.
[link]