Insane complexity of calendrically correct date and time operations • Hacker News Board

Re: Insane complexity of calendrically correct date and time operations

#31

Post by josecastillo » Fri, Sep 21, 2018, 12:32 AM UTC

I'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 day of the year" end up having simple, almost poetic answers like "calendar.ordinality(of: .day, in: .year, for: date)". And you can trust that they are correct for every calendar and every locale. Usually. [2]

[1] https://itunes.apple.com/us/app/better-day-a-complication/id...

[2] https://www.joeycastillo.com/notes/2016/09/18/of-crescent-mo...

Re: Insane complexity of calendrically correct date and time operations

#32

Post by ajross » Fri, Sep 21, 2018, 12:41 AM UTC

ggm wrote: post #19

NelsonMinar wrote: post #12

The leap second has a history of breaking computers. Pretty much every Linux server running Java broke in 2012, for example. 2009 saw a bunch of Linux kernels crashing in logging code. 2016 was mostly better except for Cloudflare: their systems had an assumption time never runs backwards. https://blog.cloudflare.com/how-and-why-the-leap-second-affe...

Not wanting to be a complete BSD bigot, I can't actually remember if this broke in the {Free,Net,Open}BSD world as badly. The 2015 docs for FreeBSD don't help (oh, for a time machine) but go to "you can test what we do" which is good. https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-se...

Not to jump on the bigotry, but two of the three bugs mentioned in that comment were in proprietary software (Java and RRDNS) that merely runs on Linux. The hrtimer issue in 2012 was a real kernel bug though.

Re: Insane complexity of calendrically correct date and time operations

#33

Post by severine » Fri, Sep 21, 2018, 12:43 AM UTC

teddyh wrote: post #9

This could very well have been called “ Falsehoods programmers believe about date and time calculations ”. It fits very well into the pattern of other similarly titled lists which have been published in recent years.

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".

Re: Insane complexity of calendrically correct date and time operations

#34

Post by JdeBP » Fri, Sep 21, 2018, 12:48 AM UTC

vortico wrote: post #2

Is it true that Unix time is as simple as it seems? Is there exactly one second between adjacent integers? Do all Unix time values occur only once simultaneously around the world?

It depends from the Unix and decisions by the local system administrator.

* https://unix.stackexchange.com/a/327403/5132

Re: Insane complexity of calendrically correct date and time operations

#35

Post by nitwit005 » Fri, Sep 21, 2018, 1:16 AM UTC

xenadu02 wrote: post #13

jchw wrote: post #7

Many of these make the weird assumption that you want to support multiple calendars. For better or worse, this is rarely the case.

I think that's a bit naive. Properly supporting calendrical calculations serves two major purposes: 1. Serve the billions of people who don't use the Gregorian calendar or who live in areas that don't match your idea of time zones. 2. Functions as a human form of "platform independence". Properly handling dates/times quickly exposes places you've made silly assumptions or accidentally broken things. This protects you…

> Serve the billions of people who don't use the Gregorian calendar or who live in areas that don't match your idea of time zones.

There isn't that much use of non-Gregorian calendars in software, even in places that do make use of them. And if you do support them, it's another source of bugs, as you have to deal with new Japanese era names and the like: https://blogs.msdn.microsoft.com/shawnste/2018/04/12/the-jap...

Re: Insane complexity of calendrically correct date and time operations

#36

Post by mmt » Fri, Sep 21, 2018, 1:50 AM UTC

severine wrote: post #33

teddyh wrote: post #9

This could very well have been called “ Falsehoods programmers believe about date and time calculations ”. It fits very well into the pattern of other similarly titled lists which have been published in recent years.

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-...

Re: Insane complexity of calendrically correct date and time operations

#37

Post by draw_down » Fri, Sep 21, 2018, 1:58 AM UTC

I really dislike the tone these sort of things tend to take, which is “here’s some stuff you think but you’re wrong about.” The reason people get stuff like this wrong (and names, and addresses, and and and) is because it’s really hard to get right. And it’s added difficulty on top of writing code which is already pretty challenging.

Re: Insane complexity of calendrically correct date and time operations

#38

Post by draw_down » Fri, Sep 21, 2018, 2:01 AM UTC

drtillberg wrote: post #28

Christ Church College at Oxford still makes a limited use of 'local time' offset 5 minutes and 2 seconds from the time zone. https://greenwichmeantime.com/info/oxford/

Good grief.

Re: Insane complexity of calendrically correct date and time operations

#39

Post by akeck » Fri, Sep 21, 2018, 2:07 AM UTC

For quick scripts, I do all my date math with seconds-since-the-epoch, retrieved with "date", and then convert back at the end. The final date benefits from the latest timezone package update, so mostly I do OK.

Re: Insane complexity of calendrically correct date and time operations

#40

Post by ars » Fri, Sep 21, 2018, 2:13 AM UTC

ggm wrote: post #19

NelsonMinar wrote: post #12

The leap second has a history of breaking computers. Pretty much every Linux server running Java broke in 2012, for example. 2009 saw a bunch of Linux kernels crashing in logging code. 2016 was mostly better except for Cloudflare: their systems had an assumption time never runs backwards. https://blog.cloudflare.com/how-and-why-the-leap-second-affe...

Not wanting to be a complete BSD bigot, I can't actually remember if this broke in the {Free,Net,Open}BSD world as badly. The 2015 docs for FreeBSD don't help (oh, for a time machine) but go to "you can test what we do" which is good. https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-se...

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.