[Haskell-cafe] threadDelay delays less time than expected (Windows)

[Bardur Arantsson]

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,