Eric Siegerman wrote:
> On Tue, Sep 18, 2001 at 11:03:03AM -0400, Larry Jones wrote:
> > The problem is that the offset between UTC and local (civil) time
> > changes from time to time (at least twice per year in the case of those
> > countries that have "daylight saving" or "summer" time). So, knowing
> > what the offset is *right now* doesn't tell you anything about what the
> > offset was some time in the past.
>
> I thought localtime(3) took care of all that. Or isn't it
> portable enough?
>
On Solaris 7, according to the man page, localtime(3) takes care of daylight
savings time for the US only:
"These functions know about the peculiarities of this conversion for
various time periods for the U.S. (specifically, the years 1974, 1975, and
1987). They will handle the new daylight savings time starting with
the first Sunday in April, 1987."
Since it also uses the value of the TZ environment variable, it gives
correct answers for *current* time for other regions also. But it does not
deal with changes in the rules for daylight savings time outside the US
(e.g., EU changed the rules in 1996). If region has changed its daylight
savings time rules, the current TZ may be wrong for a date before the
change. So using localtime(3) for a date before the change may give an
incorrect answer.
More details at Sun's "Symptoms and Resolutions" at
http://sunsolve.Sun.COM/pub-cgi/retrieve.pl?doc=fsrdb%2F18171&zone_128=localtime
Given the difficulties of knowing rules for calculating dates for all
regions for all times since 1970, I would be surprised if this limitation
only existed on Solaris 7.
dtayl
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
