If a city or country changes to daylight savings time, does Apple update your computer to reflect this change? For instance, Chili changed to DST of 1 hour. Do you have to modify your script or has Apple updated it? http://www.timeanddate.com/worldclock/clockchange.html?n=232
Edited: that’s ok. I reread the “time to gmt” post and remembered that the user has to set DST on or off and is not in the TZ database (I think).
If the System PreferencePane Date & Time is set to “set date time automatically” the daylight savings time is applied automatically.
I am living in France with daylight savings time and since 2004/01/01 I never applied change by hand.
Of course this apply for a machine which is connected, at least from time to time, to the net.
KOENIG Yvan (VALLAURIS, France) vendredi 13 septembre 2013 09:09:50
I haven’t figured out precisely how this works, but this is something I believe unix takes care, probably a kernel extenstion.
It does so at the right time, because in the date and time part of the locale info in /usr/share, there is zone info files, that are compiled, and contains exactly that information. This was a topic not a long time ago.
Basically, when you either change your localization in the time preferences, or when you boot, I guess that this information is read in, and after that, it is a timer like mechanism, that sees if it has to change the time settings within the next 24 hours or so.
As I said, there was a whole thread about this recently, the files and such: this thread contains applicable information follow the link in post #6. (Not the white rabbit. )
Yes, for America/Santiago, I just checked the time to gmt in the summer (-4 hours) and now it’s (-3 hours). Wonder where they keep that stuff also.
I have to add Nigel’s modificaitons (from the link) to the formatting in the following script I’ve used to test that:
on TZtoTZ(TZ1date, TZ1, TZ2)
return (do shell script ("eraTime=$(TZ=" & TZ1 & " date -jf '%Y-%m-%dT%H:%M:%S' '" & (TZ1date as «class isot» as string) & "' '+%s') ; TZ=" & TZ2 & " date -r \"$eraTime\" '+%Y-%m-%dT%H:%M:%S'") as «class isot») as date
end TZtoTZ
on timeToGMT on dt for TZ
return dt - TZtoTZ(dt, TZ, "GMT")
end timeToGMT
set dt1 to date ("09/13/2013 12:00")
set localTZ to "America/Santiago"
timeToGMT on dt1 for localTZ
set r to result
r / 3600
I executed apropos timezone in a terminal window, (man -k timezone would have returned the same) then I got as a result: timezone(3) - return the timezone abbreviation
tzfile(5) - timezone information
zdump(8) - timezone dumper
zic(8) - timezone compiler
I think man -s8 zic will tell you what you are curious about. b[/b]
There is a lot of stuff in this street, that aren’t exactly as you’d think they are, -so it is good to brush up some, or brush away old assumptions. Its refreshing!
For instance, you can only use AppleScript time to gmt handler when you use it for the current date, otherwise, you’ll have to figure out the gmt for that day.
And the gmt for a day on a given date, is good for almost anything concerning solar days, as long as you aren’t going to do anything astronmical, if, then you will have to resort to physical time to gmt, and eventually adjust with your your offset from Greenwich with your longitude converted to hours, minutes and seconds.
Saturday at 16:00:00 (GMT) equates to Sunday at 02:00:00 (+10 hours) or Sunday at 03:00:00 (+11 hours). Are those not the times your clocks go forward and back?