Modified:
  /wiki/WhyBother.wiki

=======================================
--- /wiki/WhyBother.wiki        Wed Apr 14 12:27:19 2010
+++ /wiki/WhyBother.wiki        Tue Apr 20 23:16:19 2010
@@ -15,18 +15,22 @@
  So if we start fixing the 2038 bug now, maybe, just maybe, by 2020 when  
the problem becomes acute people will have already upgraded to 2038 clean  
programs.

-== 64 bit CPU doesn't mean 2038 clean ==
-
-The problem will go away once we all start using 64 bit processors, right?
+= Objections =
+
+== The problem will go away once we all start using 64 bit processors,  
right? ==
+
+A 64 bit CPU doesn't mean y2038 clean.

  For example, your shiny new Apple computer has a 64 bit processor in it.  
But the operating system is still operating with 32 bit integers and a 32  
bit time_t and has a 2038 bug.  Why?

  When you change the integer size you need to recompile all your software.  
Then Mac applications would have to ship 32 bit and 64 bit versions.  Apple  
has dealt with this sort of thing gracefully several times in the past  
("fat binaries" for the Motorola -> PowerPC switch,  
[https://secure.wikimedia.org/wikipedia/en/wiki/Universal_binary "universal  
binaries"] for the PowerPC -> Intel switch), but it's still a painful and  
buggy process for both developer and user.  (Note: OS X 10.6 appears to  
have made the jump to 64 bit software).

-I don't blame them for not thinking it worth the effort.  Windows has had  
64 bit versions since the early nineties, and very few people use them.
-
-
-== Why not just use <insert date library here> ==
+I don't blame them for not thinking it worth the effort.  Windows has had  
64 bit versions since the early nineties, and very few people use them.  
Its a lot of work, especially in twitchy, hyper-optimized driver code.
+
+And just because you're using a shiny new 64 bit processor doesn't mean  
everyone else will.  32 bit processors will remain cheap and plentiful, not  
just in PCs and old hardware, but in your car, your phone, your watch, your  
TV, your DVD player...
+
+
+== Why not just use <insert date library here>? ==

  I looked around and couldn't find anything that...

@@ -39,3 +43,12 @@
  For example, [http://cr.yp.to/libtai.html libtai] is awesome, but it  
doesn't support time zones and doesn't look much like time.h.  I could pull  
code from BSD, but it's not portable.

  If there is such a thing, please [mailto:schw...@pobox.com let me know]  
and I'll gladly scrap this whole project!
+
+
+== But dates and time zones are meaningless X years into the past/future!  
==
+
+Let's say they are.  At what point in the future do they become  
meaningless?  What's the largest time_t you should be able to put into  
localtime() and gmtime() before your program simply stops working or starts  
returning nonsense?  I can guarantee you, whatever you think is reasonable  
someone will want to go beyond.  Library code should not unjustly limit the  
designs of the programmer.  2038 is obviously too small.  The next required  
limit is 300 billion years.  Anything between is an artificial limit.
+
+And they're not meaningless, not even time zones.  Why?  Because time  
zones, distorted as they are, are still a representation of where the sun  
is in the sky.  And that's handy information to know.  So handy that well  
done 64 bit time zone databases use solar noon to determine a city's time  
zone before there were time zones.
+
+Most 64 bit time.h's have major flaws after 2**48.  But even I think  
that's time enough.