Re: Algorithm to exploit 32 bit time functions to do time zone calculations
Michael G Schwern <[email protected]> Wed, 17 Sep 2008 17:21:15 -0700
| Newsgroups | gmane.os.miros.general,gmane.comp.lib.libtai |
|---|---|
| Message-ID | <[email protected]> |
Thorsten Glaser wrote:
> Michael G Schwern dixit:
>=20
>>>> Maybe you can shed some light on this problem, what to do about year=
0?
>>> I actually haven=E2=80=99t thought about year 0, since localtime/mkti=
me do that,
>>> and mjd2tm and tm2mjd from DJB code. I think it=E2=80=99s illegal, is=
n=E2=80=99t it?
>> Illegal according to who?
>>
>> C99 and POSIX 1003.1 define tm.tm_year as a signed int with a range of=
"years
>> since 1900" which makes a negative year perfectly "legal".
>=20
> 0 is not negative, and there has been no year 0, only 1 ante christo (-=
1)
> followed directly by 1 post christo. (Ironically, he was probably not b=
orn
> by then.)
Oh, wasn't thinking about that. I was thinking about negative years. Bu=
t
you're right, year 0 is sticky. Let's look at what ISO 8601 does...
Wikipedia claims ISO 8601-2004 treats year 0 as 1 BC, but I can't find an
explicit reference. They also claim that ISO 8601-2004 uses "Astronomica=
l
year numbering" but again, I can't find that in the standard. It just sa=
ys a
"calendar year" is "in the Gregorian calendar" (2.2.13). However, it see=
ms
perfectly sensible and I think I'll go with that.
Here's the language in 3.2.1 "The Gregorian calendar" which uses their us=
ual
"mutual agreement of the partners in information interchange" cop out
The use of this calendar for dates preceding the introduction of the
Gregorian calendar [1582] (also called the proleptic Gregorian calendar=
)
should only be by agreement of the partners in information interchange.
And in 4.1.2.1...
calendar year is, unless specified otherwise, represented by four digit=
s.
Calendar years are numbered in ascending order according to the Gregori=
an
calendar by values in the range [0000] to [9999]. Values in the range [=
0000]
through [1582] shall only be used by mutual agreement of the partners i=
n
information interchange.
They also define an expanded year format which, "by mutual agreement" all=
ows
for negative years. (4.4.3.3)
>> I wonder how a Chinese locale deals with this. They switched from Jul=
ian to
>> Gregorian after 1901, so it should show up in any Chinese localtime()
>> implementation. Also Russia and much of Eastern Europe.
>=20
> I think a =E2=80=9Cstruct tm=E2=80=9D is just always gregorian, since o=
ther calendars
> do not neccessarily have the same day/month/year concept (example:
> Japanese).
I've got a call out for someone to test what a properly localized Unix di=
st
does, just to get a data point.
--=20
"I went to college, which is a lot like being in the Army, except when
stupid people yell at me for stupid things, I can hit them."
-- Jonathan Schwarz