[y2038] r185 committed - Another OS X bug.

3 views
Skip to first unread message

codesite...@google.com

unread,
Mar 1, 2010, 7:25:43 PM3/1/10
to y2038-...@googlegroups.com
Revision: 185
Author: schwern
Date: Mon Mar 1 16:24:47 2010
Log: Another OS X bug.
http://code.google.com/p/y2038/source/detail?r=185

Modified:
/wiki/AmazingDiscoveries.wiki

=======================================
--- /wiki/AmazingDiscoveries.wiki Sat Feb 13 05:04:11 2010
+++ /wiki/AmazingDiscoveries.wiki Mon Mar 1 16:24:47 2010
@@ -11,7 +11,9 @@

Despite now using 64 bit CPUs (Intel Core Duo 2) still uses 32 bit
integers and time_t, presumably to avoid having 32 and 64 bit versions of
software. So it fails at the normal 32 bit boundries.

-10.6 appears to have fixed this, but a new bug emerges. gmtime(-2**52)
loses a day somewhere. BSD, DateTime.pm, Linux and y2038's own
implementation all agree its Mon Jan 25 20:11:44 -142711421 but OS X says
its Mon Jan 24th.
+10.6 appears to have fixed this, but a new bug emerges. gmtime loses Dec
31st, -2235476. It ticks over from Dec 30th, 23:59:59, -2235476 to Jan
1st, 00:00:00, -2235475 causing all subsequent calendar dates to be off by
a day. This has been reported to Apple as bug 7654647.
+
+Another bit of 10.6 fun. timegm() and mktime() both hang at
gmtime(-4136232677718). This is Wed Jan 1 14:24:44 -129102. This has
been reported to Apple as 7704213.


== OpenVMS ==

Reply all
Reply to author
Forward
0 new messages