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

[David Turner]

On 29 December 2016 at 22:27, Joachim Durchholz <jo at durchholz.org> wrote:

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


Hmm, I dunno, "complicated" implies it's at least possible to define a
function which correctly add physical times to calendar times, which isn't
true - you can't reliably calculate the calendar time exactly 400*86400
seconds from now because the result depends on whether there's a leap
second or not and they're not announced that far ahead of time. I really
think "dangerous" is a better word, although the word "unsafe" might be
more Haskellish.

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.
> (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.)
>
> 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 to this. Note that the distinction goes all the way down to the OS - see
the CLOCK_REALTIME and CLOCK_MONOTONIC options to
https://linux.die.net/man/3/clock_gettime for instance, and there is
similar functionality within Windows. Doing any kind of timing-based things
with CLOCK_REALTIME (and derivatives) is kinda flawed because it can run
slow and/or jump backwards if NTP is fiddling with it. CLOCK_MONOTONIC is
the right thing to use for that.

OTOH sometimes I want to say "sleep for 50 seconds" and sometimes I want to
say "sleep until the current (calendar) time is X". As the delay API
doesn't currently support both of these, you have to do the unsafe
conversion between calendar times and durations to do both kinds of sleep.
Fortunately it's rare to care about waking up at a particular second 6
months into the future so this mostly works just fine.

Some of these thoughts are implemented here:
https://hackage.haskell.org/package/alarmclock

Cheers,

David







>
>
> [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.
>
> Regards,
> Jo
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20161230/1e55c213/attachment-0001.html>