On Feb 20, 2010, at 6:42 AM, Mark J. Reed wrote:
On Sat, Feb 20, 2010 at 4:03 AM, Nathan Vander Wilt
<email@hidden> wrote:
My AppleScript code needs to send and receive dates from another utility, and passing them as seconds from the Unix epoch seems like it should be the most reliable. To achieve this, I set the following property at the top of my script:
property unixEpoch : (date "Thursday, January 1, 1970 12:00:00 AM") + (time to GMT)
Hm. Apart from the outdated time zone designation "GMT", the function
"time to GMT" is poorly named; I'd expect, from the name, that it's
what you add to local time to get GMT, but in fact it's what you add
to GMT to get local time. But never mind.
The problem is that (time to GMT) returns the offset as of *now*, when
the script is run. That's different from the offset at the time in
question, because in June, Daylight Saving Time is in effect. That's
the source of your 1-hour discrepancy. You need something that will
tell you the offset to UTC as of an arbitrary date, not just as of
now. Which is a hard thing to do, given the way the DST rules have
shifted over time and space.
I was assuming that AppleScript treated dates internally like Cocoa does: as seconds from a reference date. But I'm getting the impression that within an AppleScript script itself, dates are stored (and *calculated*!) internally just as the class is writable externally: four numbers YMD+S and some elementary calendar assumptions. (Thanks Shane for corroborating on this.)
Some research leads me to believe that in the actual Apple Events sent between my script and the application it is targeting, these dates will have been converted to a LongDateTime (which *is* a number of seconds from an epoch). So somewhere across that boundary, AppleScript must be converting them from/to its local calendar representation in a sensible manner.
So here's my new plan of attack:
1. Transfer dates in and out of AppleScript as 5 numbers: Year, Month, Date, Day seconds, Time to GMT.
2. Don't do any date calculation in my script itself, except to adjust an input date so it matches the current "time to GMT" (which mercifully does not change while a script is running).
3. AppleScript will translate between its local representation to a standard time as it communicates with scriptable applications.
Are my new assumptions correct?
thanks,
-natevw |