Zeugswetter Andreas SB writes:
 > Try the attachment with negative values, and tell us whether mktime
 > returns anything other that -1. Do you have an idea how else we
 > could determine daylight savings time ?

mktime always returns -1 for tm's that might expect to return a
negative number.  In those cases the tm is not normalized and
tm_isdst is set to -1.  When mktime returns zero or positive then tm
is normalized and tm_isdst is set to 0 or 1.

localtime sets all the fields of tm correctly, including tm_isdst, for
all values of time_t, including negative ones.  When I say correctly,
there is the usual limitation that the rules to specify when DST is in
force cannot express a variation from year to year.  (You can specify
e.g. the last Sunday in a month.)

My observations were consistent across AIX 4.1.5, 4.2.1, and 4.3.3.


If you have a time_t, then you can use localtime to determine DST.  If
you have a tm then you cannot work out DST for dates before the epoch.
One workaround would be to add 4*n to tm_year and subtract (365*4+1)
*24*60*60*n from the time_t returned.  (All leap years are multiples
of 4 in the range 1901 to 2038.  If tm_wday is wanted, that will need
to be adjusted as well.)  But don't you do time interval arithmetic
using PostgreSQL date types rather than accepting the limitations of
POSIX/UNIX?
-- 
Pete Forman                 -./\.- Disclaimer: This post is originated
WesternGeco                   -./\.-  by myself and does not represent
pete.forman@westerngeco.com     -./\.-  opinion of Schlumberger, Baker
http://www.crosswinds.net/~petef  -./\.-  Hughes or their divisions.

Thu, 11 Jan 2001 13:22:06 +0000
Pete Forman <pete.forman@westerngeco.com>
Re: AW: AW: Re: tinterval - operator problems on AIX
Pete Forman writes:
 > One workaround would be to add 4*n to tm_year and subtract (365*4+1)
 > *24*60*60*n from the time_t returned.  (All leap years are multiples
 > of 4 in the range 1901 to 2038.  If tm_wday is wanted, that will need
 > to be adjusted as well.)

FWIW, that should be to add 28*n to tm_year and subtract (365*4+1)*7
*24*60*60*n from the time_t returned.  That calculates tm_wday
correctly.

Also I should have been more explicit that this applies only to AIX
and IRIX.  Those return -1 from mktime(year < 1970) and do not allow
DST rules to vary from year to year.  Linux and Solaris have more
capable date libraries.
-- 
Pete Forman   http://www.bedford.waii.com/wsdev/petef/PeteF_links.html
WesternGeco                           http://www.crosswinds.net/~petef
Manton Lane, Bedford,               mailto:pete.forman@westerngeco.com
MK41 7PA, UK                  tel:+44-1234-224798  fax:+44-1234-224804

Thu, 11 Jan 2001 14:08:59 +0000
Pete Forman <pete.forman@westerngeco.com>
Re: AW: AW: Re: tinterval - operator problems on AIX
> FWIW, that should be to add 28*n to tm_year and subtract (365*4+1)*7
> *24*60*60*n from the time_t returned.  That calculates tm_wday
> correctly.
> Also I should have been more explicit that this applies only to AIX
> and IRIX.  Those return -1 from mktime(year < 1970) and do not allow
> DST rules to vary from year to year.  Linux and Solaris have more
> capable date libraries.

Oh, so AIX and IRIX have just one-line time zone databases? Yuck.

How about having some #if BROKEN_TIMEZONE_DATABASE code which uses both
mktime() and localtime() to derive the correct time zone? That is, call
mktime to get a time_t, then call localtime() to get the time zone info,
but only on platforms which do not get a complete result from just the
call to mktime(). In fact, we *could* check for tm->tm_isdst coming back
"-1" for every platform, then call localtime() to make a last stab at
getting a good value.

Comments?

                        - Thomas

Thu, 11 Jan 2001 15:31:24 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: AW: AW: Re: tinterval - operator problems on AIX