Earlier quoted context omitted.
https://infiniteundo.com/post/25326999628/falsehoods-program... edit: which cites https://infiniteundo.com/post/25326999628/falsehoods-program... (from HN's own patio11) as inspiration, as the original "Falsehoods programmers believe about X".
I think you meant it cites https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
Insane complexity of calendrically correct date and time operations
121–130 of 146 posts
Re: Insane complexity of calendrically correct date and time operations
#122> Weeks start on Sunday in the United States, Monday in Europe, and a couple of places start on Saturday. Wow. I live in Europe, and find it weird that people can consider the week to start on Sunday. I guess everything that may appear normal within a cultural frame of reference can be off in another, even the most basic of things!
I mean … I was aware of the fact that the week starts on Sunday in a LOT of other places. But still. So Sunday, the first day of the week, is still part of what's called the weekend, right?
Correct. Which, if one thinks about it, the start of something is one end of it. (said tongue in cheek)
Re: Insane complexity of calendrically correct date and time operations
#123As the ephemeral Tom Scott also demonstrates [0], even IF you account for all the listed factors (and many more) you are STILL sometimes out of sync, just due to the nature of the power grid itself.
As Albert said: Time is what clock measure. The more you dig into it, the more you realize how true that is!
Re: Insane complexity of calendrically correct date and time operations
#124Yours in calendrical heresy, JS
Just as well this article doesn't contain a technique for locally making P=NP. I've never trusted Vidona, and I never will.
Re: Insane complexity of calendrically correct date and time operations
#125Earlier quoted context omitted.
But offset of UTC for TAI is like 37 seconds or something poxy like that. Nobody cares about this, the sun moves too slowly for that to make any difference. There's been talk of setting UTC=TAI for quite a long time and I think it'd make sense. It'd take so long for TAI to drift from the actual rising and setting of the sun that we'd probably all have standardised on Swatch Beats by then anyway.
Yes, the difference is 37 seconds now, but it's growing quadratically. It's quite possible that we'll change the way we express times and dates, but it's almost certain that we'll want them to stay in phase with the sun, and we'll probably want to stick with the SI second and with something like TAI. My guess is we'll continue to want a simple relationship between TAI (or its successor) and the civil clock time, some…
I feel like throwing in a leap hour (basically tz shift) once in a millenia would be more reasonable solution, if for nothing else than letting future generations deal with it instead of trying to futilely pre-empt problems that are not really problems yet.
Re: Insane complexity of calendrically correct date and time operations
#126Earlier quoted context omitted.
If you said that to me at work, I'd understand Monday, because Sunday is not part of the work week. I'd likely understand it as Monday in other contexts too, because it's very rare for something to start on Sunday. Monday and Saturday are the transition points and thus the logical places to start doing something. But I might understand it as Sunday if context seemed to point that way. What I'm saying is that nothing…
No hard implications, but it might influence how you number the days (C99's tm_wday uses 0-6 with 0 = Sunday, which suggests a week starting with Sunday, particularly since tm_mon uses 0-11 with 0 = January, but is also compatible with the way the days are numbered in Chinese, with Monday = 1), and it might be related to how you work out which months have 4 weeks and which months have 5 weeks: it's unusual, but some…
> it's unusual, but some part-time employees get 4 weeks' pay at the end of most months but 5 weeks' pay at the end of some months, bizarrely.
Why would this be unusual? I'd expect pay-by-the-week to be more common for part-time employees, but it's not rare for FTEs either.
Re: Insane complexity of calendrically correct date and time operations
#127I think on of the best attempts to fix calendar system was done by George Eastman (Kodak founder), who presented "International Fixed Calendar" created by Moses Cotsworth to League of Nations in 1923. At that time League of Nations was trying to redesign current calendar system and was accepting different proposals. Unfortunately they failed to come to consensus between different calendar designs :( https://en.wikipe…
That calendar's weeks start on Sunday and I would rather have hours vary by length of daylight throughout the year than start weeks on bloody Sunday.
Re: Insane complexity of calendrically correct date and time operations
#128Earlier quoted context omitted.
There's now "Google time".[1] This handles by leap seconds by making each second slightly longer, starting 12 hours before the leap second and ending 12 hours after it. [1] https://developers.google.com/time/smear
And there's also UTC-SLS. But a more important distinction than whether you smear over +/-12 hours or +/-1000 seconds is whether you broadcast a bogus time signal to all your hapless servers, which is what Google does, I think, or whether you fix your kernel and C library so that the system knows the real time but reports UTC-SLS to those programs which use the old APIs and are therefore presumed to be incapable of u…
Old APIs won't be the only problems, it's easy to introduce bugs like this new API or not (it's much easier to say use monotonic timers these days, but it's still easy for devs not to use th=em)
Re: Insane complexity of calendrically correct date and time operations
#129I've encountered just about every item on this list working on my Apple Watch complication, Better Day[1], which supports 11 calendar systems in 21 languages. The funny thing is, the last item on this list — always use ICU through the NSCalendar API — is the exact conclusion I arrived at, and one that I preach to anyone who will listen. Especially with modern Swift syntax, complex questions like "what's the current d…
I only skimmed your article, but are you sure that's right? There must have been at least several date adjustments before your app was release yet the system time maintained the correct date. Presumably it'll correct afterwards, invalidating the date offset.
The thing to keep in mind is that before the sighting, the months are pre-calculated for when the first crescent moon should rise over Mecca. So a change only affects the single month where the observation differed. For example, if you're expecting to see the first crescent moons on October 10, November 9 and December 8, but you didn't see the first one until October 11, that doesn't push the moon sightings out for the rest of the year. It just means that the month you thought would end on October 9 will have an extra day, and the month you thought would start on October 10 will start a day later (and as a result will be a day shorter).
Future months are still totally fine; the date offset is just a temporary fix that the user remembers to turn on when the announcement is made, and to turn off at the end of the month.
Re: Insane complexity of calendrically correct date and time operations
#130Earlier quoted context omitted.
BSD is actually worse, it doesn't handle leap seconds at all, it simply ignores their existence and assumes the clock was simply inaccurate. That's fine as far as it goes, but make sure never to use a BSD machine as an NTP server or you will cause a lot of confusion for any servers downstream.
I don't know about OpenBSD or NetBSD but I've witnessed FreeBSD handling leap second correctly. I also witnessed OpenNTPD ignoring it and that's documented, so I suspect OpenBSD doesn't handle leap seconds at all.
There's more on this at https://news.ycombinator.com/item?id=18039595 .