Re: [MacPerl-Porters] MacPerl daylight saving time issue
On Sat, 28 Sep 2002, Jarkko Hietaniemi wrote: 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. It would appear that VMS and Mac OS have this property too. On the matter of DST and geography under Mac OS I did manage to find a web page at Apple: http://developer.apple.com/techpubs/macosx/Carbon/text/DateTimeUtilities/Date_Time_an_nt_Utilities/index.html That asserts that: You can use the routines provided by the Date, Time, and Measurement Utilities to, ... get and set the geographic location and time-zone information, etc. and in Mac OS 9 the relevant headers are apparently DateTimeUtils.h and UTCUtils.h. I have yet to find a clear example of the geographic location or TZ determination. However, it would seem that if I can determine the current localtime(), the current UTC time, the current dst setting, and if I can accurately (meaning take DST transition into account) determine the localtime vs. UTC time difference for some other date then I should be able to determine the dst setting for that other date by calculating today's UTC offset and comparing the quantities. Peter Prymmer
Re: [MacPerl-Porters] MacPerl daylight saving time issue
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. 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 [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
Re: [MacPerl-Porters] MacPerl daylight saving time issue
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
Re: [MacPerl-Porters] MacPerl daylight saving time issue
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
Re: [MacPerl-Porters] MacPerl daylight saving time issue
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
