* Leap second bug? @ 2008-06-07 20:40 Ondrej Zajicek 2008-06-08 19:45 ` Ondrej Zajicek 2008-06-08 22:00 ` Ludovic Courtès 0 siblings, 2 replies; 7+ messages in thread From: Ondrej Zajicek @ 2008-06-07 20:40 UTC (permalink / raw) To: guile-user [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Leap second bug? 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 1 sibling, 0 replies; 7+ messages in thread From: Ondrej Zajicek @ 2008-06-08 19:45 UTC (permalink / raw) To: guile-user [-- 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 --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Leap second bug? 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 2008-06-10 15:15 ` Jon Wilson 1 sibling, 2 replies; 7+ messages in thread From: Ludovic Courtès @ 2008-06-08 22:00 UTC (permalink / raw) To: guile-user 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Leap second bug? 2008-06-08 22:00 ` Ludovic Courtès @ 2008-06-09 14:58 ` Greg Troxel 2008-06-09 17:18 ` Keith Wright 2008-06-10 15:15 ` Jon Wilson 1 sibling, 1 reply; 7+ messages in thread From: Greg Troxel @ 2008-06-09 14:58 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-user 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Leap second bug? 2008-06-09 14:58 ` Greg Troxel @ 2008-06-09 17:18 ` Keith Wright 0 siblings, 0 replies; 7+ messages in thread From: Keith Wright @ 2008-06-09 17:18 UTC (permalink / raw) To: gdt; +Cc: ludo, guile-user > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Leap second bug? 2008-06-08 22:00 ` Ludovic Courtès 2008-06-09 14:58 ` Greg Troxel @ 2008-06-10 15:15 ` Jon Wilson 2008-06-10 18:26 ` Ludovic Courtès 1 sibling, 1 reply; 7+ messages in thread From: Jon Wilson @ 2008-06-10 15:15 UTC (permalink / raw) To: guile-user 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Leap second bug? 2008-06-10 15:15 ` Jon Wilson @ 2008-06-10 18:26 ` Ludovic Courtès 0 siblings, 0 replies; 7+ messages in thread From: Ludovic Courtès @ 2008-06-10 18:26 UTC (permalink / raw) To: guile-user 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2008-06-10 18:26 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2008-06-09 17:18 ` Keith Wright 2008-06-10 15:15 ` Jon Wilson 2008-06-10 18:26 ` Ludovic Courtès
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).