Re: Algorithm to exploit 32 bit time functions to do time zone calculations
Michael G Schwern <[email protected]> Wed, 17 Sep 2008 14:03:19 -0700
| Newsgroups | gmane.os.miros.general,gmane.comp.lib.libtai |
|---|---|
| Message-ID | <[email protected]> |
Thorsten Glaser wrote: >> My main targets are Perl, Python and Ruby which have to be absurdly po= rtable. >> As I understand it, almost nothing about the time zone database is por= table. >=20 > Oh, okay. This is a step further away from Unix. It's about nine. :) If you're morbidly curious, take a look at the suppo= rted platform list for Perl. http://perldoc.perl.org/perlport.html#Supported-Platforms >> For example, I could not expect tzload() to work on all operating syst= ems. I >> would have to ship my own, which I do not want to do, or write time zo= ne code >> for each operating system, which I also do not want to do. >=20 > You probably could just take the entire Olson time library in its origi= nal, > portable state, and change that. (This would have the beneficial side e= ffect > to replace vendors=E2=80=99 probably buggier time libraries and time zo= ne databases > with something known to work.) I've considered that, yes system libraries are often suspect, but I don't= want to now have each application with its own independent time zone library t= hat has to be updated by the user independent of the system's own. Odds are,= it won't get updated. > But I like your =E2=80=9Cwrapping=E2=80=9D approach. Thanks! Maybe you can shed some light on this problem, what to do about year 0? = Right now the only limit I have on dates is the limit of what Time64_T can stor= e. Does it make sense to stop at 0? I've seen a number of implementations t= hat do. My thinking for gmtime() is that a negative year is just BC, so let = it go! localtime()... well, localtime() gets absurd real fast. Gregorian/Julian calendar shifts. The time zone simply not having existed in the past. I= t's really hard to say what the locals would have thought the datetime was X seconds ago. Any insights? --=20 You are wicked and wrong to have broken inside and peeked at the implementation and then relied upon it. -- tchrist in <31832.969261130@chthon>