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
That’s alright, I need to see ‘environ’.
Thanks,
kel
the 12/24 hour setting in Date & Time is just the display mode,
the system locale settings are located in Language & Text > Region
In this particular case, I just used “Europe/Berlin” because that’s what juergen said was his time zone in post #6. One way to get the time zone on the local computer is, as in post #16, to parse the POSIX path pointed to by the symbolic link “/etc/localtime”:
set localTZ to (do shell script ("readlink '/etc/localtime' | sed 's|/usr/share/zoneinfo/||'"))
This was interesting, I started to dig a little into the zoneinfo files that lies below /usr/share.
When I use the command zdump zoneinfo/US/Hawaii I get the current time back, according to the manual, in utc. So, they don’t do much useful, the commands to read tzone files from the shell. I think you’ll have to set the LC_TZ to something for their usefullness to kick in.
I was hoping to get the offset or something, instead I ended up with the knowledge that leap seconds aren’t included in posix time (seconds since epoch.) 
(man time2posix)
What you’re seeing is correct; you’re just not looking at the full picture. Change your script to this:
set dt1 to date ("26.10.2013 12:00")
set dt2 to date ("27.10.2013 12:00")
log dt1
log dt2
(dt2 - dt1) / hours
Now go to System Preferences, Language & Text, and change the Medium format for time display so that it also includes the timezone. Run the script and look at the logged values. You might now agree with AppleScript 
If you want to do much with AS dates, the key is to ignore the string value, and just deal with the underlying components.
Hello everybody,
I found a pretty good list here:
http://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/timezone.html
Here’s a better list that contains the daylight savings times offset:
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
It’s better to use the same list as the mac does, that is the IANA Time Zone Database. Here you can download the plain text versions of the files that are serialized in /usr/share/zoneinfo. When downloading these plain text files you can look into these files and see the history of time settings.