On 2016-12-29 23:27, Joachim Durchholz wrote:
Am 29.12.2016 um 22:41 schrieb Bardur Arantsson:
(Of course there must be *some* way to 'convert', but those conversions are inherently dangerous and should be clearly marked as such.)
Actually you don't convert, but you can add physical time to a calendar date. It's not really dangerous, just complicated - leap years which follow a rule, leap seconds that you have to look up in a table.
True, but... it's *complicated*... which was my point. Add in the fact that the entries in that table may not even *exist* yet, depending on the duration! If you're programming with a Duration and you're counting on a machine to get leap seconds right -- you're doing something wrong.
You don't do historic calendars; it's even dubious that you need Islamic or other calendars unless you do either religious or historic dates, in which case domain-specific code would probably be appropriate.
My favorite observation is that there's actually a February 30th[1]... which anyone who *really* wants to be correct about calendar behavior has to observe. [1] https://en.wikipedia.org/wiki/February_30
Leap seconds are "unsafe" in the IO sense: they occur at irregular times and are not predictable, so this addition is not referentially transparent. I can't think of a use case for this kind of addition in application code though: Either you do calendar calculations, and then you add calendar seconds to a date, with the usual 24:60:60 factors for days/hours/minutes/seconds. Or you do timing-related code: timers that go off, benchmarks, and in both cases you start with a timestamp and add physical seconds, which is trivial.
Exacly, so I don't think *physical* time (like a Duration) should even attempt this. Beause the leap second is entirely artifical, invented to keep the *calendar* ("Earth" time) in sync with *physical* time.
(In system code, the NTP stack or some local driver needs to keep track how physical time relates to calendar time, but that's nothing you'd need or want in a standard library.)
We agree again!
tl;dr: physical time and calendar time are different concepts, have different uses, and the use cases for mixing the two are so rare that conversion code shouldn't go into any kind of standard library. IMHO.
[1] Bascially before JodaTime made ordinary developers aware of just how complex this Time/Date stuff really is and the importance of clearly separating the concept of "calendar" time vs. "physical" time.
Yeah, that's a really awesome library, and well worth looking at if you want fresh time API ideas.
Actually, the Java 8 standard "time" library is -- in many ways -- even better, it's been simplified to account for the fact that 99% of people don't actually need to account for e.g. Julian (or $OTHER) chronologies. If you need that kind of functionality, you're already out in the weeds and you probably need to implement your own library *anyway*. (I'd argue that the 30th of July in Sweden falls into the same category, simply because going back to the 1700s is mostly *academic* to most people. I dunno. I know that it would take me a long time to flick through my Google Calendar to get back that far.) Regards,