That is correct, you can’t go wrong, as long as the dates are ordered, so that the end dates ends after the start date, and the two dates are alike.
As long as the dates are after 1 january of 1970, you can do the same with the unix date command, (convert two dates to seconds, subtract them with expr, and them format back to hours minutes and seconds.
I guess you can do it in FileMaker too (but I haven’t figured it out yet,) I guess you can do the same in Numbers, and Excel too. (Thing is, sometimes it is easer to just enter hours, minutes and seconds in different spread sheet columns, and that is what this really have been centered around, and also Filemaker for that matter, because there at least I enter time and date in separate fields.
What if instead of using the fixed start date, create your own start date like 2000. Never mind me I don’t know what I’m talking about but just throwing out things so disregard if not useful.
Anyway, darn forgot what I was working on! Might be getting close to to sleep time.
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.
Edited: in fact, I think the Colonel wanted to give me a medal!!!
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:
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.
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.
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.
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.
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.
I agree to everything you have written above on a general basis.
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”.
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.
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.
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.
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 .!
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.
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
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?
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.
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.
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.
Might be getting close to to sleep time.
