Hi,
If I use:
time to GMT
-->- 36000
that means -10 hours from Greenwich time right? i.e. GMT is correct? I think it must be true because I used -10 in the sunrise and sunset calendar. Some program said it was -11. I wonder if that’s with daylight saving time? We don’t have daylight saving time in Hawaii.
Thanks,
It’s the current time from GMT according to the locale you have set in the Time Zone panel of System Preferences, including any difference for daylight savings. The Closest City matters, because not all places in a time zone necessarily have the same rules for daylight savings.
Hi Shane,
Found the closest city in System Preferences. Was wondering if ‘time to gmt’ was connected to something I set.
Thanks a lot,
kel
Timezone’s doesn’t have daylight saving time. The only difference is that in the UK (not Ireland, but I’m not sure about that) they switch between GMT and BST (British Summer Time). In Europe we switch between CET (Central Europe Time) and CEST (Central Europe Summer Time). The time zones itself never changes time, for summer time/daylight saving time we just switch timezones.
So to answer your question: Because you aren’t switching timezones for summer time, the difference between your timezone and Greenwich Mean Time should be the same all year.
Hi DJ Bazzie Wazzie,
That’s good to know. Because I started up this computer before daylight savings time started (sprang forward). The an app I ran was wrong in thinking time to gmt was -11. ‘time to gmt’ is already preset, according to your settings in System Preferences for Time Zones’ closest city.
Thanks,
kel
Hi DJ Bazzie Wazzie,
are you sure? Olson time zones (https://en.wikipedia.org/wiki/Tz_database) know about summer time (daylight saving time) since 1970. That is exactly the reason, why Europe/Paris is not the same as Europe/Amsterdam. Both cities have the same system for standard time / summer time today. But they did not always since 1970.
Today on my machine (in time zone Europe/Berlin), “time to GMT” returns 7200, i.e. two hours. Berlin is one hour east of London, but we have summer time. UTC (a linguistic cross breed of Coordinated universal time and Temps universel coordonné) never has. Hence two hours difference.
And keep in mind that “time to GMT” generally makes sense for “current date” only. It does not help you to convert times in December if you are in June, unless you are in a time zone without summer time.
Jürgen
It’s even sillier than that. Change your preferences so that the date strings show the timezone, and do the calculation with dates in and out of daylight savings time. The timezone in the results is wrong (or the displayed time is wrong – take your pick).
Hello.
It is good to be informed about the bugs. Nigel Garvey provides a fix/work around in this post that works from Applescript. I haven’t really considered the day light savings time, but performing a conversion operation with some care, should get exact results.
Like considering any daylight savings time in the time zone you are currently in, if the conversion function doesn’t do it.
There are also ways to bypass this if you resort to C, althoughI can’t recollect having seen anything about towns in the locale when specifiying timezones for the the time functions. Allbeit that may be possible. I am sure the ICU library handles this correctly, but then again, I am always optimistic. 
There are probably even easier ways to resolve this in Cocoa / Objective-C, and maybe ASObjC, than in C, that also considers the town of the timezone.
You’re right Jürgen. We, the Netherlands, had our own time zone known as Amsterdam Mean Time (AMT). I think it had an 20 minute delay or something. But the Olson database isn’t an timezone as CET or UTC, it’s an geographic location with rules about their time. But today, looking at the rules in the Olson database it just sets the time zone to CET and CEST and nothing more. In other words, the rules in the Olson database is only to switch between timezones. And looking at other countries (in the europe database), the same applies, they are only switching between WET/WEST, CET/CEST and EET/EEST. So I consider those geographical location more as an alias or pointer to the correct timezones rather than specific time rules.
It is a combination. Rules are set differently for different years. As the Wikipedia defines: “Within the tz database, a time zone is any national region where local clocks have all agreed since 1970”. The names of time zones typically combine a continent name and a city name. Someone had the wise insight that cities tend to be more stable than country borders and names.
For a given time, the tz database matches an Olson time zone to a traditional one like BST. But it may match the same Olson tz to different traditional time zones for different dates. The following AppleScript shows that (I have a day-month-year date format, Time zone is Europe/Berlin):
set dt1 to date ("1.7.2013")
set dt2 to date ("1.7.1975")
tell application "System Events"
set pl to (make new property list item with properties {value:{dt1, dt2}})
set r to text of pl
end tell
r
(* r now is
"<?xml version=\"1.0\" encoding=\"UTF-8\"?>
<!DOCTYPE plist PUBLIC \"-//Apple//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">
<plist version=\"1.0\">
<array>
<date>2013-06-30T22:00:00Z</date>
<date>1975-06-30T23:00:00Z</date>
</array>
</plist>
"
*)
Both dates are midnight and both are in the summer. The 2013 time is two hours apart from UTC, the 1975 date is one hour apart. (We switched 1980 in Germany.) Europe/Berlin is matched to CEST for 2013 and to CET for 1975.
If you check the tz file for Asia and have a look at Israel, you will find that almost every year has its own rule. (Rules are in the Gregorian calendar. If memory serves, Israel uses the Hebrew calendar for the switch in autumn so far.)
So the important points to keep in mind:
If your region has no daylight saving time (like Hawaii in the original question) and never had, “time to gmt” can be used to convert from local time to UTC and vice versa.
In all other cases, conversion is tricky. Have a look at Nigel’s script that McUsrII linked above.
(Just another nasty effect:
set dt1 to date ("26.10.2013 12:00")
set dt2 to date ("27.10.2013 12:00")
(dt2 - dt1) / hours
returns 24.0
Actually the difference is 25 hours difference in my time zone.)
Jürgen
Hello.
I believe I have the same daylight savings time as Juergen, provided that the 27.10.2012 or whatever date was the last sunday of october. The subtraction of the two dates fail to take the extra hour into account as you move the time forward again, (You can sleep one hour longer :)).
The smoothest way I can think of when it comes to calculate time intervals between timezones, is to convert to seconds since Epoch, and convert from seconds since Epoch back into date/time.
That is ok, when you are dealing with whole years, since it will even out over a year. If you convert a date/time for a Timezone (TZ) into seconds since Epoch (1970.01.01:00:00 ) I think that calculation should be calculated correctly by the date functions. But you have to use the correct TZ at that given point in time. (Daylight savings or not).
The same thing goes around, when converting from seconds since Epoch to a timezone, you’ll have to know the end result, maybe perform a preflight operation, to see what date you’ll end up with, and then perform the calulcation again, if the date/time is within daylight savings time. (Or just subtract the factor).
This is a hard one to fix in AppleScript. But there are handlers for converting from a date to seconds since Epoch, I can’t remember those functions consider TZ last time I looked, but that shouldn’t be to hard to fix, by setting LC_ALL or LC_TZ in between the calls to the unix date function.
This should at least be as “clean” a solution as it is possible to get. however, some heuristics for dealing with the individual timezones, is needed, you’ll have to know if daylight savings time is active in the timezone for the end-date you are converting to. (And you’ll of course have to use the correct timezone forthe timezone you are converting from.
(This post became heavily editied. :))
Hi everybody,
Great information as always. Just want I wanted to know about the time zones also.
Thanks a lot,
kel
Hello.
I edited my post heavily! My conclusion is that applescript date-objects, aren’t practical for anything else, than working with the time and date in your local timezone, if you work with several timezones, then having variables with time to Epoch in seconds, may turn out to be simpler to deal with. ( I believe a date object in Applescript ends up with being in local time anyway.)
But of course, using my handler:
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
set dt1 to date ("26.10.2013 12:00")
set dt2 to date ("27.10.2013 12:00")
(TZtoTZ(dt2, "Europe/Berlin", "GMT") - TZtoTZ(dt1, "Europe/Berlin", "GMT")) / hours --> 25.0
Now, if they ever remove class isot, we’ll have to turn up in Cupertino. And send an invoice later of course. 
Nice handler Nigel!
Or a slightly more useful ‘time to GMT’ function:
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 ("26.10.2013 12:00")
set localTZ to (do shell script ("readlink '/etc/localtime' | sed 's|/usr/share/zoneinfo/||'"))
timeToGMT on dt1 for localTZ
Hi Nigel,
When I run your script:
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
set dt1 to date ("10/26/2013 12:00")
set dt2 to date ("10/27/2013 12:00")
(TZtoTZ(dt2, "Europe/Berlin", "GMT") - TZtoTZ(dt1, "Europe/Berlin", "GMT")) / hours --> 25.0
I get -24. Did I miss something?
That’s ok. I see it is relative to your computer’s settings (where you are).
Possibly your computer’s set for a 12-hour clock and “12:00” is being compiled as midnight instead of midday.
Hi Nigel,
Setting System Preferences to 24 hour clock didn’t make it work, but adding PM to the times did work.
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
set dt1 to date ("10/26/2013 12:00 PM")
set dt2 to date ("10/27/2013 12:00 PM")
(TZtoTZ(dt2, "Europe/Berlin", "GMT") - TZtoTZ(dt1, "Europe/Berlin", "GMT")) / hours --> 25.0
Where do you get the locations from like “Europe/Berlin”?
Thanks,
kel