Date bug in Numbers?

I believe I’ve found a bug in Numbers and AppleScript.

Basically some dates are returned to AppleScript incorrectly.

To reproduce, make a new, numbers document. Set the value of the first cell of the first row to “11/11/2023”

Format the cell as time, using one of the more verbose formats (Sat Nov 11, 2023) for example.

The window should show the formatted date in the first cell.

Now, open and run the following script:

use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions

tell application "Numbers"
   tell its document 1
      tell its sheet 1
         tell its table 1
            set cellValue to value of cell 1
         end tell
      end tell
   end tell
end tell
date string of cellValue
display alert date string of cellValue
return cellValue

Rather than displaying the date Sat Nov 11 I get " Friday, November 10, 2023" in both Script Debugger and Script Editor. Also when run as an applet.

Also if I change the date to 11/12/2023 I get the Saturday date.

Can anyone reproduce?

Not sure whether it’s a bug or not but it’s probably related to daylight savings time.

Add a time component, e.g. "11/11/2023 16:00" and see what happens. You should get November 11 at 15:00, i.e. one hour before your time.

When you don’t include a time, it defaults to midnight. Subtract an hour from midnight and suddenly it’s the day before. Dunno if it’s the same date everywhere but here, the clocks move back an hour the week before that date.

If you set the date instead to a day prior to the time shift, e.g. November 4, then the issue should go away — or for that matter, a date after next spring’s reversion to DST, say June 4, 2024. Oh, and I think that it’s an applescript issue, not a Numbers issue.

1 Like

When I don’t include a time it’s defaulting to 11 pm, but why would the Sunday date give me the Saturday date?

Either way, if it displays as a date in the application, AppleScript should use that date too, without making any changes.

The clocks change next week. That’s why you’re getting the Saturday. When you don’t include a date, it uses midnight. Move the clock back an hour and suddenly it is 11:00 pm on Saturday instead of midnight Sunday.

As far as I can tell, Applescript doesn’t account for daylight savings time.

AppleScript.sdef defines:

date n : Absolute date and time values

date string: the date portion of a date-time value as text

Where I am, the clocks go back on October 29.

If I run your script with any date in November, I see the same results as you. If I run your script with an October date before the 29th, the ‘correct’ date is displayed.

Which suggests to me that AppleScript is looking at the November date and time in Numbers, detecting that it falls after the clocks go back, and deducting an hour.

Add:
This works as expected:


tell application "Numbers"
	tell its document 1
		tell its sheet 1
			tell its table 1
				set cellValue to value of cell 1
				set value of cell 2 to cellValue
			end tell
		end tell
	end tell
	end tell
1 Like

Thanks, all. It’s definitely related to the end of Daylight saving time, and it’s either a bug or a really really poor design.

@estockly, you’re right: it’s an internal bug.

The workaround is to use the formatted value to get a string:

tell application "Numbers"
	set theValue to formatted value of cell 1 of table 1 of sheet 1 of document 1
	return date string of ((date theValue) as date)
end tell

As you can see, there’s no call to the scripting additions osax.
That’s because Numbers has its own class for date.
The strange thing is that the entry in the dictionary is a perfect copy of the scripting additions one.