[MacPerl-Porters] MacPerl daylight saving time issue
Thomas Wegner
to make a long story short: In the past, I have sent some Mac OS
patches to Steffen Beyer for his Date::Calc module. He just released
Date::Calc 5.1, which is basically version 5.0 plus Mac OS Classic
support. While running the module tests for a pre-release version, I
noticed 3 failures, all related to the daylight saving time flag.
$dst is 0 for winter time, and 1 for summer time (and -1 if not
supported). Said tests check if $dst == 0 for a given date and fail.
My Mac is currently set to summer time, hence I first thought that
$dst is correctly set to 1. But Steffen reminded me, that on Unix,
Windows etc. the daylight saving time flag is set according to the
given date. For instance, on December 24th, 2001, $dst should be 0
(see the sample script below), right? But obviously, if a Mac is set
to summer time, and I check the Christmas Eve date, $dst will be 1
(!). My conclusion: $dst depends on the Date&Time control panel
setting, and not on a given date. I won't say this is a bug, but it
is, isn't it? :-)
I am confused, to be honest. Is this a known issue (in GUSI, I
think), or a bug in my brain? Ideas?
#!perl -w
use Time::Local;
$time = timelocal(0, 0, 12, 24, 11, 2001); # Dec 24th, 2001 12:00:00
($sec,$min,$hour,$day,$month,$year,$dow,$doy, $dst) = localtime( $time );
$year += 1900;
$month += 1;
print "year= $year\n";
print "month = $month\n";
print "day = $day\n";
print "hour = $hour\n";
print "min = $min\n";
print "sec = $sec\n";
print "doy = $doy\n";
print "dow = $dow\n";
print "dst = $dst\n";
__END__
Result:
year= 2001
month = 12
day = 24
hour = 12
min = 0
sec = 0
doy = 357
dow = 1
dst = 1 # daylight saving time, should be 0 on Dec 24th, 2001 ???
Regards,
Thomas.
Chris Nandor
>I am confused, to be honest. Is this a known issue (in GUSI, I
>think), or a bug in my brain? Ideas?
This is a known bug in GUSI, and Matthias has no plans to fix this
difficult problem.
http://sf.net/tracker/index.php?func=detail&aid=456334&group_id=7941&atid=107941
His note:
>Sigh. This is bad, and pretty much uncorrectable. My only consolation
>is that I'm apparently in good company (I saw the same behavior
>on a Solaris system that I tested this on).
I have nothing to add to that. :-)
--
Chris Nandor pu...@pobox.com http://pudge.net/
Open Source Development Network pu...@osdn.com http://osdn.com/
Peter Prymmer
On Fri, 13 Sep 2002, Thomas Wegner wrote:
> Hi,
>
> to make a long story short: In the past, I have sent some Mac OS
> patches to Steffen Beyer for his Date::Calc module. He just released
> Date::Calc 5.1, which is basically version 5.0 plus Mac OS Classic
> support. While running the module tests for a pre-release version, I
> noticed 3 failures, all related to the daylight saving time flag.
> $dst is 0 for winter time, and 1 for summer time (and -1 if not
> supported). Said tests check if $dst == 0 for a given date and fail.
> My Mac is currently set to summer time, hence I first thought that
> $dst is correctly set to 1. But Steffen reminded me, that on Unix,
> Windows etc. the daylight saving time flag is set according to the
> given date. For instance, on December 24th, 2001, $dst should be 0
> (see the sample script below), right? But obviously, if a Mac is set
> to summer time, and I check the Christmas Eve date, $dst will be 1
> (!). My conclusion: $dst depends on the Date&Time control panel
> setting, and not on a given date. I won't say this is a bug, but it
> is, isn't it? :-)
While I cannot comment on any possible problem in GUSI I can
tell you that the message regarding Unix and Windows behavior
from Steffen is incorrect. 24 December 2001 may have $dst == 0
for many Northern latitudes, while it may have $dst == 1 for many
Southern lattitudes (i.e. those south of the equator).
The settings of daylight savings time is a political matter
and rather difficult to capture accurately in computer
programming, since among other things laws regarding the
setting of daylight savings times depends on laws that
may be written well after an operating system or programming
language is released. At least on Unix the rules are
easily amended by careful placement of symlinks in the
filesystem (at linux implements it that way).
For "convenient" examples of how complex the rules can be
try to determine the GMT offset of eastern and western
Indiana in the US for different dates. Now do the same
exercise for each of the Australian states (they have
30 minute and 45 minute offsets from the hours GMT offset).
For what it is worth I think that the result you obtained
is perfectly fine for e.g. Sydney on 24 Dec 2001.
Peter Prymmer
Chris Nandor
>For "convenient" examples of how complex the rules can be
>try to determine the GMT offset of eastern and western
>Indiana in the US for different dates. Now do the same
>exercise for each of the Australian states (they have
>30 minute and 45 minute offsets from the hours GMT offset).
I think this is why Matthias said the problem is not solvable in GUSI.
Unless Mac OS supplies an API for it (which at this point is more than
unlikely, being that Mac OS is EOL'd) ... I don't know how this data would
be figured out by GUSI.
Also note that Israel's DST changes from year to year arbitrarily (not
based on any particular calendar or regular schedule) and IIRC Iraq's is
based on the Muslim calendar or somesuch; and other countries change what
schedule they use every decade or so. Fun fun fun.
Thomas Wegner
>While I cannot comment on any possible problem in GUSI I can
>tell you that the message regarding Unix and Windows behavior
>from Steffen is incorrect. 24 December 2001 may have $dst == 0
>for many Northern latitudes, while it may have $dst == 1 for many
>Southern lattitudes (i.e. those south of the equator).
>
>The settings of daylight savings time is a political matter
>and rather difficult to capture accurately in computer
>programming, since among other things laws regarding the
>setting of daylight savings times depends on laws that
>may be written well after an operating system or programming
>language is released. At least on Unix the rules are
>easily amended by careful placement of symlinks in the
>filesystem (at linux implements it that way).
>
>For "convenient" examples of how complex the rules can be
>try to determine the GMT offset of eastern and western
>Indiana in the US for different dates. Now do the same
>exercise for each of the Australian states (they have
>30 minute and 45 minute offsets from the hours GMT offset).
>
>For what it is worth I think that the result you obtained
>is perfectly fine for e.g. Sydney on 24 Dec 2001.
>
>Peter Prymmer
Thanks, Peter. To clarify things: Steffen said, that the DST setting
on Unix and Windows depends on a given date. I think this is
absolutely correct. I have provided the Christmas Eve example, and it
was bad example, I must confess, now that I have read your email. As
it happens sometimes, a problem that seems to be trivial, turns out
to be very complicated.
Best regards,
Thomas.
Peter Prymmer
On Mon, 16 Sep 2002, Thomas Wegner wrote:
> Thanks, Peter. To clarify things: Steffen said, that the DST setting
> on Unix and Windows depends on a given date. I think this is
> absolutely correct. I have provided the Christmas Eve example, and it
I agree with you and Steffen.
> absolutely correct. I have provided the Christmas Eve example, and it
> was bad example, I must confess, now that I have read your email. As
> it happens sometimes, a problem that seems to be trivial, turns out
> to be very complicated.
Actually I do not think that your Christmas Eve example was bad. Yes
daylight savings time rules may be complicated but it "should not" be
impossible to code around (I say that as someone who has never attempted
to modify GUSI). I note that for the "Date & Time" control panel version
8.3 that ships with Mac OS 9.1 there is a checkbox for "Set
Daylight-Saving Time Automatically", from which I conclude that parts of
the system do know what time zone the Mac is in and what the DST ->
standard time -> DST calendar rules are. Hence I think that your example
should have worked since I presume that you have set your Time Zone
appropriate to running a Mac in Germany, that is in a place in the
northern hemisphere where standard time is in effect in December.
I guess I was merely pointing out how difficult it can be to write
something like the Date & Time control panel. The fact that it does not
expose DST transition rules to run time libraries like GUSI (as per Chris'
comment about the API not being there) can be considred a deficiency in my
opinion.
Peter Prymmer
Matthias Neeracher
On Wednesday, September 18, 2002, at 12:38 AM, Peter Prymmer wrote:
> Actually I do not think that your Christmas Eve example was bad. Yes
> daylight savings time rules may be complicated but it "should not" be
> impossible to code around
Not impossible, but rather hard. At some point, it also would become a
question of how much code to add to a general purpose library just to
handle a special case which is not handled on many commercial platforms
either.
> (I say that as someone who has never attempted
> to modify GUSI). I note that for the "Date & Time" control panel
> version
> 8.3 that ships with Mac OS 9.1 there is a checkbox for "Set
> Daylight-Saving Time Automatically", from which I conclude that parts
> of
> the system do know what time zone the Mac is in
Yes.
> and what the DST -> standard time -> DST calendar rules are.
Hmm, I can't check this from X, but doesn't the "Automatically" here
refer to getting the flag from a network time server? AFAIK, the last
time I checked, the three DST options available were:
- Click the checkbox yourself in spring and fall. This is obviously
unsuited to calculating future dates.
- Specify the switchover rules (2nd saturday in march) appropriate to
your location. This
would work, but there is no API to the rules.
- Get the DST setting from a network time server. This is also
unsuited to calculating any DST setting except for the present.
Matthias
Peter Prymmer
On Wed, 18 Sep 2002, Matthias Neeracher wrote:
>
> On Wednesday, September 18, 2002, at 12:38 AM, Peter Prymmer wrote:
> > Actually I do not think that your Christmas Eve example was bad. Yes
> > daylight savings time rules may be complicated but it "should not" be
> > impossible to code around
>
> Not impossible, but rather hard. At some point, it also would become a
> question of how much code to add to a general purpose library just to
> handle a special case which is not handled on many commercial platforms
> either.
Indeed it is a tough call. I cannot even say if the code belongs more
with GUSI or with MacPerl. I guess I'd rather be able to say that one
could rely on the C run time to expose things as they are done on Unix -
but I realize that may be wishful thinking. Apparently struct tm in C is
not too useful in this regard(?!).
> > (I say that as someone who has never attempted
> > to modify GUSI). I note that for the "Date & Time" control panel
> > version
> > 8.3 that ships with Mac OS 9.1 there is a checkbox for "Set
> > Daylight-Saving Time Automatically", from which I conclude that parts
> > of
> > the system do know what time zone the Mac is in
>
> Yes.
>
> > and what the DST -> standard time -> DST calendar rules are.
>
> Hmm, I can't check this from X, but doesn't the "Automatically" here
> refer to getting the flag from a network time server? AFAIK, the last
> time I checked, the three DST options available were:
>
> - Click the checkbox yourself in spring and fall. This is obviously
> unsuited to calculating future dates.
> - Specify the switchover rules (2nd saturday in march) appropriate to
> your location. This
> would work, but there is no API to the rules.
> - Get the DST setting from a network time server. This is also
> unsuited to calculating any DST setting except for the present.
I too am not completely sure if you have to rely on a Network Time Server
(presumably NTP???) for the DST on<->off switching. In particular if you
look at the control panel:
http://pvhp.best.vwh.net/mac/Date_and_Time.jpg
note that the timezone settings are grouped above, and I might suspect
independently of the "Use a Network Time Server". Unfortunately, I have
little experience with the Mac OS 9.1 version of Date and Time (Version
8.3 is the one illustrated in the jpeg image listed above) in particular
with the Network Time Server setting of it.
On the other hand, I do have some experience with the so called UCX and
Multinet NTP clients and servers on VMS. I know that when either NTP
client encounters a large gap in system time it is limited in the
adjustments it can make to the system time. I do not have the docs in
front of me, but from memory the rule is something along the lines of:
1) make no system time adjustment greater than 10 seconds in any
given adjustment attempt.
2) For large changes move only in one direction
(forward or backward - I have forgotten which)
The latter rule helps to ensure that the NTP driven time adjustments do
not make the system time "oscillate" and break time sensitive software
(e.g. databases, build systems like make that depend on file timestamps
etc.). The net effect these rules have is that you cannot rely on simply
having configured an NTP server on VMS to do the daylight savings times
for you in the spring and the fall. Indeed both tcp/ip stacks for VMS
have protected system variables like the following:
$ show logical *timezone*
(LNM$SYSTEM_TABLE)
"SYS$TIMEZONE_DAYLIGHT_SAVING" = "1"
"SYS$TIMEZONE_DIFFERENTIAL" = "-14400"
"SYS$TIMEZONE_NAME" = "EDT"
"SYS$TIMEZONE_RULE" = "EST5EDT4,M4.1.0/02,M10.4.0/02"
Hence I suspect that the "Set Daylight-Saving Time Automatically" setting
for the "Date & Time" control panel means lookup the transition rule in a
data file that ships with the control panel. I could be wrong about that.
OK enough of the discussion of another non-Unix. _If_ there were are way
to read the Mac's "Date & Time" control panel settings (I realize that
both you and Chris have said there is no API), then there could be at
least two things possible with the information, and perhaps a thrid
fallback if you cannot read any of the Date & Time settings except for
the current system time:
1) Suppose for example in the Date & Time panel I mentioned above I have
set the time zone such that it displays "New York is a city in the current
time zone." - Perhaps a complete solution would be to carry around the
full set of known DST rules for all such cities. The advantage is some
sense of completeness. The disadvantage is the need to carry around so
much tabular data, in addition to the data already in Date & Time (and
apparently inaccessible). Another disadvantage is the inflexibility.
If, e.g., the State of Indiana or Queensland decides to change its DST
rules then such a table would need updating.
2) Instead of a big table use a heuristic like apply US rules
(e.g. "TIMEZONE_RULE" = "EST5EDT4,M4.1.0/02,M10.4.0/02") everywhere
and flip the is_dst boolean for south of the Equator Cities such as
Adelaide Australia. The advantage is the reduction in the size of the
rule data you need to ship. The disadvantage is the innaccuracy of
applying US rules to places where it does not apply (i.e. your $is_dst
result in MacPerl is untrustworthy at or near the real timezone switch
date for your locale). here again having a "Preference" setting that
allows you to specify the DST rule would be quite helpful.
3) Assume you cannot read "Date & Time" settings at all and allow
"Preference" settings for either GUSI or MacPerl. Having a convenient
default for such a frequently ignored setting might be nice.
I hope that helps.
Peter Prymmer
Peter Prymmer
On Thu, 26 Sep 2002, Peter Prymmer wrote:
> I too am not completely sure if you have to rely on a Network Time Server
> (presumably NTP???) for the DST on<->off switching.
According to a FAQ just off of the page that help for the Date & Time
control panel takes you to:
http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-s-trouble.htm#S-TRBL-SPEC-MACINTOSH
According to Brian Bergstrand "If/when you upgrade to a PPC machine, OS
8.5 and above have a built in NTP client that can be activated in the
Date & Time control panel."
Another product seems to be Vremya.
Interestingly, according to:
http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-s-trouble.htm#FTN.AEN4845
The Linux kernel has no idea about the effective timezone or daylight
saving time.
According to:
http://www.lava.net/~kirill/software/vremya.html
As of February 23, 2002, Vremya 2.0.1+ is in the public domain.
The document at:
http://developer.apple.com/techpubs/macosx/Carbon/pdf/DateAndTimeAPI.pdf
makes mention of the difference between the struct UTCDateTime and
struct LocalDateTime, along with several conversion functions.
Unfortunately I have not found any place within that doc that mentions
"daylight", "savings", or "dst". I have to go now.
Peter Prymmer
Jarkko Hietaniemi
>
> http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-s-trouble.htm#FTN.AEN4845
>
> The Linux kernel has no idea about the effective timezone or daylight
> saving time.
I think in general UNIX-like kernels (thankfully) don't have any idea
of timezones or DSTs, they simply operate in UTC. All complex stuff
(like what should be done with a US user currently sitting in their UK
office accessing a database in Japan using an application in Australia)
is left to the upper layers to worry about.
--
Jarkko Hietaniemi <j...@iki.fi> http://www.iki.fi/jhi/ "There is this special
biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen