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>