To:	djgpp AT sun DOT soe DOT clarkson DOT edu
Cc:	dj AT ctron DOT com (DJ Delorie), Henrik Storner <storner AT olicom DOT dk>
Subject:	Re: New time routines
Date:	Wed, 31 Aug 94 08:33:52 +0200
From:	eliz AT is DOT elta DOT co DOT il

DJ writes:
>>                     mktime() automatically determines these
>> and uses them internally if it is called with a *negative*
>> tm_isdst.  mktime() then returns the correct settings of dst flag
>> and gmt offset in the appropriate fields of tm structure.
>
> I thought this, and tried to prove that it did what I expected, but
> couldn't see it in the code at all.  I'll try empirical tests some
> more and hope for the best . . .

I tried this: it works.  In my version of stat() it works that way.

>> that DST *might* be in effect.  It then either takes the DST offset
>> from TZ, if it's there, or (in this case) assumes it's one hour less
>> than standard offset.  If TZ doesn't contain a full Posix specification
>
> Actually, there is NO assumption.  It looks up the posixrules zoneinfo

There is a line inside tzparse() which attempts to find a number after
EDT (or such like) and, failing that, says: dstoff = stdoff - SECPERHOUR
(hope I remember it right).  It could be that going to posixrules over-
rides this setting; I couldn't really say, because I don't really under-
stand what info is taken from there and how exactly it is used, I never
bothered to give a real look at tat stuff (complicated and uncommented).

> I don't know if this is desirable behavior, but it's what actually
> happens in ctime.c, which still matches the BSD sources in that part.

I think GMT0 as the last resort is OK.  At least nobody would complain
it's US-centric or any other-centric.

Henrik Storner <storner AT olicom DOT dk> writes:
> I have mixed emotions about this. On the one hand, I agree that it would
> be nice to have the de-facto standards working like they normally do. On
> the other hand, I hesitate to change the ctime library.
>
> Let me suggest an alternative. Instead of trying to hack tzset() so that
> it works with TZ=XXXNYYY settings, modify TZ "on the fly" to be set 
> according to what Posix expects. So if TZ=EST5EDT, add some reasonable
> guess as to when DST is in effect.
>
> I've put together the following little routine, which is layered on

Why is it necessary to change the existing code of tzset()?  With the
zoneinfo files properly installed, there is a file called ``posixrules''
there which contains all the info missing from an incomplete TZ spec
like EST5EDT.  So, given a correct installation, tzset() will work
as it should right out of the box, even if TZ is EDT5EST.  And if
somebody will ever want to change the rules without changing neither
TZ setting nor posixrules, he can add a file named EST5EDT with
whatever contents he wishes, because tzset() always checks for the
file before trying to parse the TZ string itself.

	Eli Zaretskii

- Raw text -