[Pitch] Clock, Instant, Date, and Duration

[lorentey (Karoy Lorentey)]

@lorentey

IIUC, the (implicit) clock behind Foundation.Date is counting seconds with the same strategy for handling leap seconds as Unix time -- i.e., they get merged with the subsequent normal second, temporarily slowing down the clock by a factor of 2.

Aargh, this is completely wrong. I misremembered how Unix time "works" -- I thought it defined some sort of halfway-sensible continuous behavior, rather than simply repeating a second. That's not ideal.

(I assume I subconsciously refused to accept this silliness and substituted it with less terrible behavior.)

If the system's wall clock doesn't implement anything but Unix time, then I'm not sure what the stdlib can do other than to accept this.

Ideally we should also have a UTCClock that is guaranteed to handle leap seconds in a platform-independent way, but is that actually implementable? I suspect this (and similar clocks like TAIClock) should be first explored in a package outside the core stdlib.

Sadly I think my conclusion is still largely valid -- I think WallClock.Instant ought to remain compatible with Foundation.Date, and it's pretty clear that that type uses Unix time.

@xwu

...in Unix time, which is not a monotonic representation of seconds since 1970-01-01T00:00:00Z . This proposal has Date representing the actual elapsed time since 1970-01-01T00:00:00Z , not Unix time.

The proposal I'm looking at does not define what instant WallClock uses for its epoch, nor does it specify whether it uses Unix time or not.

@xwu

Meanwhile, my readings indicate that Windows has switched to TAI-based timekeeping as of some release of Windows 10, with APIs converting to UTC only when needed, so that Windows now handles leap seconds in a very standards-compliant way; therefore, retrieving the actual seconds since the epoch should be trivial, although I haven’t explored the APIs available in great depth.

OK, so Windows FILETIME implemented proper accounting for leap seconds a few years ago. AIUI, they did it by only counting future leap seconds, leaving previous ones overlapping with a neighboring regular second. (Edit: Or did they?) Interestingly, it seems the routine that splits such filetimes into calendar components implements the same sort of 2x slowdown by default as I described -- perhaps that's where I got the idea? In any case, this seems like a pretty good setup.

Nit: Which standard do you mean when you say "standards-compliant"? (Is there a standard that specifies that operating systems should use this particular behavior?)

Important note: corelibs-foundation on Windows is using FILETIME to implement Date(). If I understand correctly, this means that Foundation.Date on current versions of Windows is going to either count future leap seconds or temporarily slow down the clock around them (depending on process configuration), which will potentially make its behavior (and encoded values) incompatible with other platforms.