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
