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