There is clearly a Daylight Saving bug when communicating with Numbers. I don't know if this has been reported earlier or not, so I'll describe it here:
How to reproduce:
Preliminary: Assume you already have a spreadsheet file in Numbers open (version 3.6.1), and that the first cell in the first row is formatted as a date.
FYI: In Sweden we use international date format: YYYY-MM-DD.
tell application "Numbers"
tell table 1 of sheet 1 of front document
--Note: Daylight Saving Time started 2016-03-27
set value of cell 1 of row 1 to "2016-03-25"
return short date string of (get value of cell 1 of row 1)
end tell
end tell
--> "2016-03-24"
I.e, what I get back is a whole day earlier!!
In Numbers, the cell is "2016-03-25 00:00:00", i.e correct according to what I set it to.
But when I get the date via AS then it is interpreted as one hour earlier, which means it becomes the day before.
If, on the other hand, I set the date after the start of sumertime, e.g "2016-03-28", then it behaves correctly.
We can see that it appears to be one hour difference between Numbers and Applescript if we set a date object directly with:
date "2016-03-25"
which in Swedish expands to:
date "fredag 25 mars 2016 00:00:00"
We get:
tell application "Numbers"
tell table 1 of sheet 1 of front document
--Note: Daylight Saving Time started 2016-03-27
set value of cell 1 of row 1 to date "fredag 25 mars 2016 00:00:00"
return (get value of cell 1 of row 1) --In this case we get the complete date, including the exact time.
end tell
end tell
--> date "fredag 25 mars 2016 00:00:00"
I.e, it appears to work well know, but if we look into Numbers, the cell is now:
"2016-03-25 01:00:00"
I.e, it is one hour ahead! I did set it to midnight, but it became 1 o'clock in the morning!
If I do the same thing but on the 28 March, then it will remain midnight also in Numbers.