While tinkering with this script I saw some things that I do not know about/understand.
First, this is my date format:
set this to "1-1-2000" -- using system's separator
set theDate to date this --> date "zaterdag 1 januari 2000 00:00:00"
short date string of theDate --> "01-01-2000"
But this also works:
set this to "1/1/2000"-- NOT the system's separator
set theDate to date this --> date "zaterdag 1 januari 2000 00:00:00"
short date string of theDate --> "01-01-2000"
A case of “this always worked like that”? Didn’t see it mentioned anywhere.
That script I tinkered with no longer works in 10.6 - not with my date format, anyway.
This fails on my system, as it should:
set this to "1/31/2000"
set theDate to date this --> error, as expected on my dd-mm-yyyy system
But same thing goes haywire when using system’s separator:
set this to "1-31-2000" -- now using system's separator
set theDate to date this --> date "woensdag 19 januari 2011 01:31:00"
Even weirder: It does not even depend on the fact that the hyphen is your system separator. My settings are German (dot is the separator) and the behavior is the same: 1 and 31 are interpreted as time, the date is set to today and 2000 is ignored. (I changed it to 10000 just for fun: The result is the same.)
It seems that AppleScript first tries to make it a date (if day and month are in the proper order, it works), if that is not possible, it tries a time. “date (“1-59-2000”)” works (yields 1:59 of today), “date (“1-69-2000”)” yields an error.
This is just one more example for: Never create a string and convert it to a date. This will use the locale settings of your system and a code like “date (“1-2-2011”)” will yield different dates in US and UK! As in your example, even more “smartness” may come in. (The parenthesis in my example keeps the string a string on compile time and it will be converted to a date runtime. I.e. the locale settings when the script is running will determine if this is first of Feburary or second of January!)
Always start with “current date” and set time, day, year, month and day afterwards. (Really set day twice, first to something below 29. Else there are cases where it does not work.)
AppleScript’s date parser has always been very clever. It does its best to deduce what the information you give in the string means in the context of the user’s Date and Time preferences. Any details it thinks have been omitted it takes from the current date and time. Surplus data at the end, it ignores.
set this to "10 30, time for coffee"
set theDate to date this --> date "Friday 21 January 2011 10:30:00" on my UK system.
It often ignores separators altogether; but it’s been a bit stricter since Leopard, which may account for the difference when using slashes.
You can also compile a date under your own preferences and it will appear correctly on other machines according to the preferences there. So instead of calling the ‘current date’ function when you want to construct a date, you can begin with a compiled 1st January in any convenient year between 1583 and the present. This saves the function call and does away with the need for the extra day setting. Obviously it’s not so good if you’re distributing your code in text form rather than as a compiled script.
If you got that result this morning, your computer clock’s a couple of days out.
the release notes for AppleScript coming with system 10.6 state:
(My emphasis.)
That does not sound quite the same as “Any details it thinks have been omitted it takes from the current date and time” to me.
“date (“1-2”)” returns 1:02 of today. So does “date (“1-2-”)”. “date (“1”)” and “date (“1-”)” fail. So the old logic of filling in missing values from current date is not exactly what AS does any longer. It seems, AS tries to interpret the string as a date according to strict rules first, if that fails, it tries to interpret the string as a time - according to strict rules again.
Regards, Jürgen
P.S.: Sure, compiled dates are stable. I prefer current date exactly for the reason that code may be distributed as text. But the point I wanted to make: If you need to calculate a date like next Christmas, never try to construct a string first, but start with a date and change its properties.
Sorry. Yes. “Any details it thinks have been omitted it takes from 00:00:00 on the current date.”
And if that fails, it may apply less strict rules as before.
-- All tests with AS 2.1.2 in Mac OS 10.6.6.
"01:02:03" -- My time separators.
date result --> date "Friday 21 January 2011 01:02:03"
"01 02 03" -- No separators.
date result --> date "Saturday 1 February 2003 00:00:00"
"01 57 03" -- Impossible month figure.
date result --> "Friday 21 January 2011 01:57:03"
"01 02 03 04" -- On earlier (UK) systems, this gave date "Saturday 1 February 2003 04:00:00"
date result --> date "Saturday 1 February 2003 00:00:00"
"01/02/03/04/05/06" -- My date separators. This gave date "Saturday 1 February 2003 04:05:06" on earlier systems."
date result --> date "Saturday 1 February 2003 00:00:00"
"01:02:03:04:05:06" -- Previously "Thursday 4 May 2006 01:02:03"
date result --> date "Friday 21 January 2011 01:02:03"
"01 02 03 04 05 06"
date result --> date "Saturday 1 February 2003 04:05:06"
"01-02-03-04-05-06"
date result --> date "Saturday 1 February 2003 04:05:06"
"01.02.03.04.05.06"
date result --> date "Saturday 1 February 2003 04:05:06"
Jürgen, Nigel, thanks for the discussion. I was aware of most (not all) things. But the solution I found for a 10.6 version of jonn8’s routine mentioned above just looked odd. Hoping to get another view I presented the original’s problem in a condensed form, as it were.
It is clear now that building a date object from text is silly, and getting the user’s date format no longer necessary.
At least, I cannot think of a situation where such a routine would be useful.
[The new routine works, starting from ‘current date’].
Ha! No, I wrote that on wednesday. Couldn’t post it then; some glitch at MacScripter’s ISP had locked me out.
