From: Greg Troxel <gdt@ir.bbn.com>
To: ludo@gnu.org (Ludovic Courtès)
Cc: guile-user@gnu.org
Subject: Re: Leap second bug?
Date: Mon, 09 Jun 2008 10:58:49 -0400 [thread overview]
Message-ID: <rmik5gy3b9y.fsf@fnord.ir.bbn.com> (raw)
In-Reply-To: <874p8337ub.fsf@gnu.org> ("Ludovic Courtès"'s message of "Mon, 09 Jun 2008 00:00:44 +0200")
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.
next prev parent reply other threads:[~2008-06-09 14:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-07 20:40 Leap second bug? Ondrej Zajicek
2008-06-08 19:45 ` Ondrej Zajicek
2008-06-08 22:00 ` Ludovic Courtès
2008-06-09 14:58 ` Greg Troxel [this message]
2008-06-09 17:18 ` Keith Wright
2008-06-10 15:15 ` Jon Wilson
2008-06-10 18:26 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=rmik5gy3b9y.fsf@fnord.ir.bbn.com \
--to=gdt@ir.bbn.com \
--cc=guile-user@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).