Zeugswetter Andreas SB writes:> Try the attachment with negative values, and tell us whether mktime> returns anything
otherthat -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.
