AM/PM in AppleScript

They should really document how it works in a Technical Note, no matter how inadequate, so at least we know what to reckon with, and what not. This doesn’t matter for most people anyway, and it is really no problem in translating to a time date system that works like julian day numbers in this area, but the whys, are really good to have covered, for those it matters for. This is inside the timespan the date functions are supposed to work, so it ought to be documented properly, whether it is buggy behaviour, or not.

Well yes, but I don’t think it’s intended. The real problem is that all the date manipulation and formatting is done using Cocoa dates, whereas AS uses the legacy date format from the pre-OS X days. This is one of those cases where the conversion causes problems.

If you change your system date formats so that the GMT offset shows, you will see that the offset in the date string changes by the same amount, so the string is correct; you could argue that that the confusion is being caused because you’re asking for the full date to be truncated. But then you’ll also see that the display string is often wrong in terms of daylight savings, with recent dates reflecting the DST status of the current date, rather than whether it’s in force at the time of the date being displayed.

The travails of a time traveller…

All of this should be documented in a Technical Note. It is more of an emotional issue than a technical one, I for one, prefer light shed on some deficiencies, which is a fair thing, rather to know that there exists dark corners, which is highly disturbing. -It is!

The problem with correct local sidereal time, is really, that the locale database doesn’t have the necessary resolution, which is the geodesic coordinates of the position, where the time is to have happened.

It is also good to know, that we have to look up in the “timesystem database”, what kind of daylight savings time was in action at a specified date, at a place, and if necessary adjust. (I’d really like to see this documented too, with a “how to fixit by yourself”.)

They should just hand over the docs to Nigel, -with a paycheck, and have him write it out. :wink:

That’s probably Apple’s excuse. :wink:

On my machine (admittedly set to Coventry time, not London), the break occurs at date “Wednesday 1 December 1847 00:01:15”. That’s the earliest that a date’s text representation agrees with its non-text properties. Earlier than that, the text representation’s seventy-five seconds behind the properties.

Big Ben is of course the nickname for the Great Clock of Westminster’s Great Bell, the original of which wasn’t cast until 1856 and was never installed because the Clock Tower wasn’t yet completed and the bell cracked during testing. As for a digital face, well .! :wink:

Hello.

Coventry is about 1.5 degrees west of London and Greenwhich, so the discrepancy in time if it was local sidereal, should have been around 6 minutes after (+0.1), and not 75 seconds. :slight_smile:

I suspect they use a single value for for the whole time zone, in which case I’d put my money on London rather than Coventry. Maybe Nigel will take a trip to London and tell us :slight_smile:

I don’t think they have any – but I wouldn’t be surprised if this sort of thing was one of the reasons everything but AppleScript uses a different time system. And when the system prints an NSDate, by default it always includes the GMT offset.

You mean visitors still have to work out which one’s the big hand? :wink:

I thought 6 minutes would be the correct time if they used local sidereal, if it wasn’t, if they used one time for the whole area, then it is off by 75 seconds towards Greenwhich mean time, which at least should be the preferred time then. So, where did the 75 seconds go, and why don’t they go away if you use properties instead of a time string? That is the question. :confused:

They didn’t; they just changed the offset to GMT.

Ok, I am utterly confused now. Say if they did sidereal time, first of all, then the day has 23 hours 56 minutes. so, if you subtrac that from the distance of coventry, you’ll end up with a time around 2 minutes after, and not 75 seconds, so there is a difference of around 45 seconds (which is too big a difference for me to have overlooked some calculation step), so I believe it can’t be that the deviation can be explained, by some undocumented implementation of sidereal time.

If they had used GMT all the time, then there shouldn’t be any difference at all.
If they used sidereal time, and converted the sidereal time to the GMT offset of London as a local mean, then the difference should have been 4 minutes per day.

I think I’m just dropping out of this, and will use properties of the date object when dealing with dates before 1848. :slight_smile:

Just for the record, what I started out calling local sidereal time, should have been called local mean time.

Sidereal time, devieates from mean time, as it is related to the earths position in the milky way, and not the position towards the sun, it is used by astronomers, to keep track of the sky. Therefore, the sidereal day, becomes shorter, because we don’t take the distance traveled by the sun with us, but reckons a day to be when one point at the earth is pointing towards some “firm spot” at the sky. Then the day has just 23 hours 56 minutes.

I hope that clears things up, in where I did get the numbers from suddenly. Personally, I want to forget about this, since it isn’t productive in any way. -I’ll just use properties.

A Technical Note, either explaining the bug or the feature would be handy. :slight_smile:

Then times would be an hour out during daylight savings time.

Well, I should have written GMT/BST I suppose, so the sentence should have read: If they had used GMT/BST all the time. Keeping daylight savings time out of it. But the thing is, is that there probably were no daylight savings time at that period of time.

OK. :slight_smile:

My original test script was something like this, in which I kept refining the number values to see when the strings matched the other properties and when not:

tell (current date)
	set {day, its month, year, its hours, its minutes, its seconds} to {1, 12, 1847, 0, 1, 15}
	{day, month, year, hours, minutes, seconds, date string, time string, it} of it
end tell

With my time zone set to the “Coventry - United Kingdom”, the above figures give perfect matches:

But reducing the seconds from 15 to 14 gives string results which are 75 seconds behind the other properties:

Using a date specifier instead, the following gives the expected results for the Coventry time zone:

{day, month, year, hours, minutes, seconds, date string, time string, it} of (date "Wednesday 1 December 1847 00:01:15")

But when the “15” is edited to “14” here, the script text recompiles to 75 seconds later .

{day, month, year, hours, minutes, seconds, date string, time string, it} of (date "Wednesday 1 December 1847 00:02:29")

. and both the strings and other properties in the result agree with the later time. However, this recompilation anomaly only occurs with date specifiers in the 75-second range jumped when the strings catch up ” that is, any time between midnight and 00:01:14 on Wednesday 1 December 1847 compiles to 75 seconds later. Earlier than that, the specifiers compile as written, but the strings are 75 seconds behind the actual date values.

{day, month, year, hours, minutes, seconds, date string, time string, it} of (date "Tuesday 30 November 1847 23:59:59")
--> {1, December, 1847, 0, 1, 14, "Tuesday 30 November 1847", "23:59:59", date "Tuesday 30 November 1847 23:59:59"}

The time difference and flip date appear to be the same for all the “nearest cities” recognised by Yosemite on the island of Britain: from Penzance in the south-west to Ipswich in the east (east of Greenwich), Caerfyrddin (Carmarthen) in Wales, and Inverness in Scotland. And of course London. (I see there’s a separate “city” for Islington ” an area of London ” but none for Greenwich itself!) Also with Douglas on the Isle of Man and Londonderry in Northern Ireland. Testing was done by saving the above scripts in “Coventry”, quitting Script Editor, and THEN changing the time zones before reopening the scripts.

With cities in the Republic of Ireland, which is in the same time zone as the UK, the flip date is “Sunday 1 August 1880 23:59:39”, before which the AppleScript date strings are 21 seconds ahead of the other date properties.

tell (current date)
	set {day, its month, year, its hours, its minutes, its seconds} to {1, 8, 1880, 23, 59, 38}
	{day, month, year, hours, minutes, seconds, date string, time string, it} of it
end tell
--> {1, August, 1880, 23, 59, 38, "Sunday 1 August 1880", "23:59:59", date "Sunday 1 August 1880 23:59:59"}

Furthermore, the date-specifier script, saved in the Coventry time zone as .

{day, month, year, hours, minutes, seconds, date string, time string, it} of (date "Wednesday 1 December 1847 00:01:15")

. opens in Ireland as .

{day, month, year, hours, minutes, seconds, date string, time string, it} of (date "Wednesday 1 December 1847 00:01:36")

. which I suppose is to be expected, given all the other circumstances. And because the text error is in the forward direction here, no date strings are skipped at the 1880 correction and so there’s no recompilation anomaly around that time.

Odd beyond belief. :slight_smile:

Great work Nigel!

It’s the one with Robert Powell hanging from it. :wink:

http://en.wikipedia.org/wiki/The_Thirty_Nine_Steps_(1978_film)#Plot

Good grief, Nigel! here I was, suggesting a leisurely trip down to London, and you respond by taking a whirlwind tour of the British Isles. Plus a side trip to Éire, no less! I’m overwhelmed, and was forced to pay a lightning journey to Coventry myself.

I did the same on my trip to Coventry. The only difference is that I changed my string format for times in System Preferences, to show the time zone offset. And these are the results I got:

and:

Our results are essentially the same, except mine, I think, shows where the missing 75 seconds (1 minute 15 seconds) went – the goal posts were moved, as it were.

And here, taking this:

{day, month, year, hours, minutes, seconds, date string, time string, it} of (date "Wednesday, 1 December 1847 12:01:15 +0000")
--> {1, December, 1847, 12, 1, 15, "Wednesday, 1 December 1847", "12:01:15 +0000", date "Wednesday, 1 December 1847 12:01:15 +0000"}

and changing the 15 to a 14 gives this:

{1, December, 1847, 12, 1, 14, "Wednesday, 1 December 1847", "12:01:14 +0000", date "Wednesday, 1 December 1847 12:01:14 +0000"}

That’s presumably because I’m specifying the time zone difference, rather than letting it be chosen for me.

Now to scuttle back home…

:slight_smile:

I see wikipedia takes the same liberties with the name Big Ben that I did…

Hello Shane.

Can’t stay away from this, it is clearly a bug to shove the seconds into some construed timezone, if Coventry had its own timezone, it should have been listed as UTC -00:06:00, with offset to GMT. Honestly, I’ve been giving this just a quick glance, but to me it seems like it has given the offset with respect to the Coventry timezone, which is nothing anybody would suspect really, since timezones offsets, at least as I have seen them, are written relative to the Greenwhich Meredian, or what it is called, when we are dealing with UTC.

Time travelling seems like hard work, still, I think London can take it. :smiley:

Big Ben, is soon to be baptized the Elizabethian Tower or something, isn’t it, but then again, Big Ben is allways right. :wink:

Coventry is 1.5 degrees west of London, therefore it’s longitudinal coordinate is -1.5. Now, the Earth travels around the Sun with a velocity of 24 hours per revolution, which means that it uses 4 minutes on rotating one degree. (15 degrees per hour), this leaves Coventry 6 minutes after London, hence UTC -00:06:00.

Thank you Shane, it feels comforting to know where the seconds went. :slight_smile:

It’s more likely to be because you’ve changed the hour to 12. :slight_smile:

Ah – you’re right of course. But I’m not being sent to Coventry again :wink: