Leap second bug?

Leap second bug?

[Ondrej Zajicek]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]


Hello

I found this:

(use-modules (srfi srfi-19))
(define (str->date str) (string->date str "~d-~m-~Y"))
(define (date->str str) (date->string str "~d-~m-~Y"))

(date->str (time-utc->date (date->time-utc (str->date "01-01-2006"))))
-> "31-12-2005"

Is is a bug in leap second handling or is it a expected behavior?


-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Leap second bug?

[Ondrej Zajicek]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

On Sat, Jun 07, 2008 at 10:40:54PM +0200, Ondrej Zajicek wrote:
> (date->str (time-utc->date (date->time-utc (str->date "01-01-2006"))))
> -> "31-12-2005"
> 
> Is is a bug in leap second handling or is it a expected behavior?

I forgot to mention that the problem appears in both
Guile 1.6.8 and Guile 1.8.1 .

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Leap second bug?

[Ludovic Courtès]

Hi,

Ondrej Zajicek <santiago@crfreenet.org> writes:

> (use-modules (srfi srfi-19))
> (define (str->date str) (string->date str "~d-~m-~Y"))
> (define (date->str str) (date->string str "~d-~m-~Y"))
>
> (date->str (time-utc->date (date->time-utc (str->date "01-01-2006"))))
> -> "31-12-2005"
>
> Is is a bug in leap second handling or is it a expected behavior?

Not sure.  Our leap second table is up-to-date.  Apparently,
`time-utc->date' honors leap seconds, while `date->time-utc' doesn't.
In the reference implementation at schemers.org (upon which Guile's is
based), none of these two honors leap seconds AFAICS.

I'm no expert in that area but I would suggest emailing the SRFI-19
mailing list [0] for advice.  It seems that most implementations use the
reference implementation with few modifications, in which case most
implementations might be affected.  Did you try it with other Scheme
implementations?

Thanks,
Ludovic.

[0] http://srfi.schemers.org/srfi-19/

Re: Leap second bug?

[Greg Troxel]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> Ondrej Zajicek <santiago@crfreenet.org> writes:
>
>> (use-modules (srfi srfi-19))
>> (define (str->date str) (string->date str "~d-~m-~Y"))
>> (define (date->str str) (date->string str "~d-~m-~Y"))
>>
>> (date->str (time-utc->date (date->time-utc (str->date "01-01-2006"))))
>> -> "31-12-2005"
>>
>> Is is a bug in leap second handling or is it a expected behavior?
>
> Not sure.  Our leap second table is up-to-date.  Apparently,
> `time-utc->date' honors leap seconds, while `date->time-utc' doesn't.
> In the reference implementation at schemers.org (upon which Guile's is
> based), none of these two honors leap seconds AFAICS.
>
> I'm no expert in that area but I would suggest emailing the SRFI-19
> mailing list [0] for advice.  It seems that most implementations use the
> reference implementation with few modifications, in which case most
> implementations might be affected.  Did you try it with other Scheme
> implementations?

It seems very odd for time-utc->date to pay attention to leap seconds.
I would only expect leap seconds to come into play when converting
between UTC and TAI.  The whole point of UTC is to have a timescale with
the same number of seconds per day so that one can ignore the mess of
leap seconds.  Plus to have a timescale that tracks UT, which is an
astronomical time scale, which is why we have leap seconds.

With UTC, one represents seconds since the epoch in a way which does not
count leap seconds.  With TAI, the count includes all seconds (TAI-UTC currently being 33)

(I would say that a time difference of two UTC times should return the
arithmetic difference of the two seconds-since-epoch values, and of two
TAI times the same thing, but the TAI ones will have leap seconds.
This is not clear in the srfi-19 text.)

So, I'd say time-utc->date doing any leap second lookups is a bug.

Re: Leap second bug?

[Keith Wright]

> From: Greg Troxel <gdt@ir.bbn.com>
> 
> It seems very odd for time-utc->date to pay attention to leap seconds.
> I would only expect leap seconds to come into play when converting
> between UTC and TAI.

Procedure time-utc->date resents the anthropomorphism.

The author of that procedure probably paid some attention,
but not enough, otherwise the answer would be right.

> The whole point of UTC is to have a timescale with the same number
> of seconds per day so that one can ignore the mess of leap seconds.

I think this is provably false.  If anyone wants to argue, I will
look up original references, but for now I will just quote something
I wrote a few years ago, after spending much more time on this
issue than all the leap seconds in the history of the universe.

> UTC can not be expressed as a single number (in any units), but must
> be expressed as a day (either Julian Day or Gregorian Calendar
> Date), together with a time within that day (expressed as hours,
> minutes, and seconds, as total number of seconds, or as a fraction
> of a day).  This is because the days are not all the same length.
> Most of them are $86\,400$ seconds (exactly), but when a leap second
> is inserted the day is $86\,401$ seconds (exactly).

> With UTC, one represents seconds since the epoch in a way which does
> not count leap seconds.

UTC is _not_ expressed in seconds.

If it were, it would be messed up whenever a second
passed without incrementing the count.

>  With TAI, the count includes all seconds
> (TAI-UTC currently being 33)

This true (to within a second) and explains why
we don't use TIA much.  It's too hard to figure out
the date, which the boss cares about.

> (I would say that a time difference of two UTC times should return
> the arithmetic difference of the two seconds-since-epoch values, and
> of two TAI times the same thing, but the TAI ones will have leap
> seconds.  This is not clear in the srfi-19 text.)

The srfi says the input to time-utc->date is a of type
time-utc.  I don't find a definition of that in the srfi.
(There is a symbol with that name, but no type.)
It probably means a time object with component time-type
set to the symbol time-utc.  This is bad, because
a time object is a count of seconds, and UTC is not.

> So, I'd say time-utc->date doing any leap second lookups is a bug.

I don't know what a procedure should do if it is
based upon a spec that violates international standards.

> > Ondrej Zajicek <santiago@crfreenet.org> writes:
> >
> >> (date->str (time-utc->date (date->time-utc (str->date "01-01-2006"))))
> >> -> "31-12-2005"
> >>
> >> Is is a bug in leap second handling or is it a expected behavior?

I am open to argument on other things, but I am sure that
if this is expected behavior, it is bug in someone's expectations.

  -- Keith

Re: Leap second bug?

[Jon Wilson]

Hi Ludovic,

Ludovic Courtès wrote:
> I'm no expert in that area but I would suggest emailing the SRFI-19
> mailing list [0] for advice.
> 
> [0] http://srfi.schemers.org/srfi-19/

This is not recommended, because srfi-19 is "currently unsupported, and 
will likely remain so." [1]  The recommendation I got on C.L.Scheme [2] 
last summer upon submitting a patch for a different bug in the srfi-19 
reference implementation was that I submit a new srfi with the bugfix 
that explicitly obsoletes srfi-19.  I did not do this, however, because 
I was afraid that I would then be stuck as the maintainer of a srfi for 
which I did not have general expertise.

[1] http://srfi.schemers.org/srfi-19/post-mail-archive/msg00026.html
[2] 
http://objectmix.com/scheme/186335-patch-bug-srfi-19-reference-implementation-date-julian-day.html

Re: Leap second bug?

[Ludovic Courtès]

Hi,

Jon Wilson <jsw@wilsonjc.us> writes:

> Ludovic Courtès wrote:
>> I'm no expert in that area but I would suggest emailing the SRFI-19
>> mailing list [0] for advice.
>>
>> [0] http://srfi.schemers.org/srfi-19/
>
> This is not recommended, because srfi-19 is "currently unsupported,
> and will likely remain so." [1]

Wow, that sucks given that there is no alternative API (is there?) and
this one is already in widespread use.  Some time expert should take it
over.

In the meantime, I guess we just have to make sure we have the same bugs
as others.  :-)

Thanks,
Ludovic.