AM/PM in AppleScript

In the military, I was the best snow shoveveler they had :). Cleared the snow out by the next morning. But, don’t tell anybody but my friend came along with the snow shovel before anybody came to work :D.

ps. I blew their minds how much snow I used to move. :smiley:

Edited: in fact, I think the Colonel wanted to give me a medal!!!

Still shutting down.

I should mention that Nigels way of computing a time difference is probably more accurate than mine, I think that using multiplication instead of modulus, may make my approach to computing a time difference with AppleScript, loose a second now and then, I am not totally sure of it, but I have taken height for the possibility that it may happen. In the context I am going to use it, a second doesn’t matter. but it may be important to know of, in other circumstances.

Here is my favourite time system kel, someone has actually turned it into a religion: :smiley:

The Death and Life of the 13-Month Calendar - CityLab

It is of course a shame that it is so hard to make AppleScript shovel snow. But then again, its good excercise, as long as your back can take it. :wink:

Hi Mcusr,

They, in that article are schizos. Just like us! No but seriously. The more accurate you can get is the best. I’ve used algorithms that seemed like they would work, but one month or day I forget, it was off by just a few time spans. Your’s were very accurate though and I haven’t seen differences between that and the international ones.

The great thing about your data is that it’''s accurate even more accurate than the current app that I was using. And you don’t need to look up the info in tables. on the internet As I said there was that one day when it was wrong and yours was right and that opened my eyes.

Besides that, your calculations do not depend on tables taken from the internet. I know you had a little help from others such as Nigel, but piecing together all the parts is a major part of the job. And a great job it does. I’d rely on your calculations more than any other person and can see in your work the quality that anyone can rely upon.

I Still haven’t put it all together in the Calendar, but use your calculations as references. I compare your outcomes to some dates and as I have said, you have proved them wrong. Maybe soon on my part when I do make a Calendar I’ll inform you.

Thanks a lot man,
kel

Hello.

I have pondered whether the multiplication and divisison approach is more inaccurate than using mod, and my conclusion is that may be so, if the number of seconds in difference between td and yd are enormous. :slight_smile:

You should really thank Nigel, a lot more than me, or at least no less, for the Sunrise, Sunset things kel, he did write the original port of the script, unsolicited, and he got all the math right, and it is the accuracy of the math you are addressing here, and not the UI. :slight_smile:

And it was that other guy that made the algorithms, and if you aren’t talking about the sunset/sunrise, but about moon or other tables, then, I have just used algorithms I have found, and implemented them.

Hi McUsrII.

Both methods appear to get the same results with dates as far apart as 1st January 0001 and 31st December 9999. But the div/mod method should explicity coerce the seconds result to integer in case the difference really is that large .

-- date "31 December 9999 00:00:00"
set endDate to (current date)
tell endDate to set {its day, its year, its month, its day, its time} to {1, 9999, December, 31, 0}

-- date "1 January 0001 23:59:59" (proleptic Gregorian)
copy endDate to startDate
tell startDate to set {its day, its year, its month, its time} to {1, 1, January, days - 1}

if (startDate > endDate) then error "I can't have that start date is after end date!"

set timeDiff to endDate - startDate
set hourDiff to timeDiff div hours
set minDiff to timeDiff mod hours div minutes
set secDiff to timeDiff mod minutes as integer

{hourDiff, minDiff, secDiff}
--> {87649368, 0, 1}

. and for accuracy, yours should perform the “borrow” operations from the seconds up rather than from the days down:

-- date "31 December 9999 00:00:00"
set endDate to (current date)
tell endDate to set {its day, its year, its month, its day, its time} to {1, 9999, December, 31, 0}

-- date "1 January 0001 23:59:59" (proleptic Gregorian)
copy endDate to startDate
tell startDate to set {its day, its year, its month, its time} to {1, 1, January, days - 1}

if (startDate > endDate) then error "I can't have that start date is after end date!"

set dayDiff to ((endDate - (time of endDate)) - (startDate - (time of startDate))) div days
set hourDiff to dayDiff * 24 + (hours of endDate) - (hours of startDate)
set minDiff to (minutes of endDate) - (minutes of startDate)
set secDiff to (seconds of endDate) - (seconds of startDate)

if (secDiff < 0) then set {secDiff, minDiff} to {secDiff + 60, minDiff - 1}
if (minDiff < 0) then set {minDiff, hourDiff} to {minDiff + 60, hourDiff - 1}

{hourDiff, minDiff, secDiff}
--> {87649368, 0, 1}

In both cases, it should be noted that AppleScript has a long-standing bug whereby the string representations of dates earlier than approximately 1 January 1848 00:00:00 are out by a number of seconds depending on whereabouts in the world you are, so such dates must be created by setting date properties rather than using a date specifier.

Also, of course, something other than ‘text -1 thru -2 of (“0” & hourDiff)’ should be used if the hours figure’s likely to exceed 99. :slight_smile:

Hello Nigel.

I agree to everything you have written above on a general basis. :slight_smile:

That dates aren’t reperesented correctly before 1848 is very disturbing really, but, as long as the properties works all right, something should be possible to work out.

It is hard to figure out what time it really was anywhere, before the implementation of standard times, which first began being implemented in the US in 1883, before that, everybody really used local sidereal time (local noon), from their nearest centre, (or so I believe). In such cases, we’ll really have to consider local sidereal time, which dictates a time adjustment relative to the coordinates, of the place from where the time “originated”. :smiley:

Edit

By local sidereal time, I really meant that 12’O clock noon in those days, was perceived to be at the time the sun was at its highest point (zenit) right above the observer. So every city in a country in those days, had their own version of 12’O clock noon, related to the city’s longitude.

Have a nice friday! :slight_smile:

FWIW, I believe that’s what the string representation Nigel spoke of is trying to do. So if you take midday on the day standard times were introduced in, say, London, the time displayed on Big Ben’s digital face exactly 24 hours earlier would have differed by the discrepancy Nigel is seeing. Same time, different GMT offset, hence different display.

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.