Outdated leap second table in SRFI-19 about chez-srfi HOT 7 CLOSED

from chez-srfi.

My current design is at https://github.com/johnwcowan/r7rs-work/blob/master/TimeAdvancedCowan.md. It is both more comprehensive than SRFI 19 (it handles time folds, for example) and less so (it does not make much sense to convert monotonic time to hours, minutes, and seconds, much less a calendar date, since the epoch is unknown). It does not include anything about formatting.

from chez-srfi.

from chez-srfi.

Leap seconds are added pretty sparsely nowadays: only three leap seconds in the last decade, last one was in 2016. So updating the hard-coded tables in Scheme codebases ought to be a good-enough first pass.

As a long-term solution, +1 for system call. As a fallback, use hard-coded table or read a well-known file like @weinholt suggests.

A while ago, Windows added a feature whereby its clock can display :60 when a leap second occurs. This must mean they also added a system call where one can get requisite information, and unless I misthought something, they have to store a leap second table in the kernel. Hopefully they have a syscall to read that table into userland, but not sure.

from chez-srfi.

For future Scheming, I'd like a simple SRFI with:

(leap-second-table) -> return a vector of known leap seconds as integers; each positive value is a positive leap second, each negative value is a negative leap second; the magnitude is the timestamp since 1970

(tai-now) and (utc-now) -> get the current time since 1970 in TAI and UTC. could be returned as seconds; nanoseconds pair/values or seconds.fractional_seconds inexact real or seconds integer.

(tai->utc timestamp table) and (utc->tai timestamp table) -> convert between tai and utc using the given leap second table.

from chez-srfi.

from chez-srfi.

@johnwcowan has a plan for at least one new time SRFI since SRFI 19 had some kind of fundamental problem. I forget the details.

from chez-srfi.