On Thu, Feb 23, 2012 at 11:14 PM, Vitaly Magerya <vmagerya@gmail.com> wrote:
>
> Will you provide it before June 30, 2012 (when the next leap
> second occurs)?

Yes, although since the time of that second is already known,
you only need the functionality before the second after that,
probably several years hence (if the proposal to abandon leap
seconds doesn't go through - they will decide this in 2015).

I personally think leap seconds are fine, it's just POSIX
time that's the problem.

> Well, the worst case is when an implementation obtains TAI
> from correct POSIX time using outdated leap second tables.
> (In this case TAI will both jump and lie).

As will POSIX time using outdated leap second tables.

Admittedly, it's easier to use the host system's POSIX time
which (hopefully) has up-to-date tables than to re-implement
the table lookup, but as I said we will provide utilities for this.

Basically you either want to access the internal NTP libraries
(with the leap-second? bit) or more simply and portably parse
either of

  ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
  ftp://time.nist.gov/pub/leap-seconds.3535228800

(or a local copy thereof) every 6 months.

> My argument is this: all useful things you can do with TAI, but
> cannot do with current-jiffy, can (and should) be done using a
> proper date library (the one that reports 23:59:60 on leap seconds).

POSIX time can't represent 23:59:60.

> Since you can't implement such a library using only TAI (you need
> leap second and timezone tables), and since it's problematic to
> obtain TAI on many current systems, I argue that R7RS-small should
> only provide a timer (current-jiffy), and R7RS-big should provide
> a full date library.

Either way R7RS-large will include a full date/time library.

However, the proper basis for this is a single monotonic
time, which is the intermediary used in most calendrical
calculations.  Furthermore, timestamps are useful by
themselves without any notion of calendar, so I think we
should include this basis in the small language.  Since
POSIX time is not monotonic, the only options are based
on TAI.

--
Alex

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports