Re: Issues subtracting Unix epoch from date
Re: Issues subtracting Unix epoch from date
- Subject: Re: Issues subtracting Unix epoch from date
- From: Nathan Vander Wilt <email@hidden>
- Date: Sat, 20 Feb 2010 14:51:32 -0800
On Feb 20, 2010, at 12:18 PM, Mark J. Reed wrote:
> On Sat, Feb 20, 2010 at 3:10 PM, Nathan Vander Wilt
> <email@hidden> wrote:
>> 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.)
>
> The internal representation used by Applescript has nothing to do with
> this, really. I mean, UNIX uses a count of non-leap seconds since Jan
> 1, 1970 at midnight GMT, but it still honors daylight saving time
> rules in effect at the target time (not just the present) when asked
> to convert to local time. All that matters is the interface to the
> system - you are specifying a date using year, month, day, hour,
> minute, and second, no matter what AppleScript turns that into before
> manipulating it.
The way the calculations are done does matter! How many seconds are there between the Unix epoch and 2007-June-30 17:05:00 PDT?
AppleScript:
property unixEpoch : (date "Thursday, January 1, 1970 12:00:00 AM") + (time to GMT)
log (date "Saturday, June 30, 2007 5:05:00 PM") - unixEpoch
--> (*1.1832519E+9*)
Cocoa:
NSDate* date = [NSDate dateWithNaturalLanguageString:@"Saturday, June 30, 2007 5:05:00 PM"];
printf("%f\n", [date timeIntervalSince1970]);
--> 1183248300.000000
So AppleScript says 1183251900 seconds, while Cocoa gives the correct answer of 1183248300 seconds.
> Your bug came about due to daylight saving time, and if you're using
> local time at all, you can't really avoid dealing with DST issues. For
> instance, in the US, does 2AM on the day we "fall back" correspond to
> 7200 or 10,800 seconds after midnight? Well, both; without specifying
> a time zone to indicate which 2am you mean, there's no way to choose
> between them.
I'd love to avoid local time, but when I use AppleScript to ask an application for a date it only gives me access to a local calendar representation instead.
Here's an equivalent to what I need to do:
1. Get a date from an application (e.g. tell application "iPhoto" to get date of some photo)
2. Store a representation to disk, then exit script
3. Time passes, time zone offset may change.
4. Start script, load stored representation from disk
5. Set the *same* date (or a precise adjustment thereof) back to the application
This is impossible to do with AppleScript's date model. (Or please show how I am wrong?) Having the stored representation include the value of "time to GMT" when written is no solution, because it does not indicate whether the local calendar values had been adjusted for DST.
> The fact that "time to GMT" doesn't change while the script is
> running, even if it runs across the DST switch (which I've just
> verified) is a bug, IMO.
It depends. Consider a script meant to display the current GMT time:
set localTime to current date
-- moments pass
return localTime - (time to GMT)
If the time zone were to change at the point labeled "moments pass", the script could return something hours off due to AppleScript's calendar date representation. As it is, the AppleScript representation of localTime and Scripting Addition's "time to GMT" at least stay consistent.
IMO, AppleScript's knuckle-counting "How many days hath September?" calendar math is the real bug.
thanks,
-natevw _______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden