GNU bug report logs - #16663
emacs/calc/date

Previous Next

Full log

View this message in rfc822 format

From: Jay Belanger <jay.p.belanger <at> gmail.com>
To: Bart Nielsen <bart.utahman <at> gmail.com>
Cc: jay.p.belanger <at> gmail.com, 16663 <at> debbugs.gnu.org
Subject: bug#16663: emacs/calc/date
Date: Wed, 05 Feb 2014 22:03:33 -0600

> (What I think I'm doing is creating a vector with 10 year increments,
> in
> seconds, and wanted to know if you honored, or don't honor, leap
> seconds.

It doesn't honor leap seconds.  The manual points out:
   Today's timekeepers introduce an occasional “leap second” as well,
   but Calc does not take these minor effects into account. (If it did,
   it would have to report a non-integer number of days between, say,
   ‘<12:00am Mon Jan 1, 1900>’ and ‘<12:00am Sat Jan 1, 2000>’.)  
Maybe more importantly, leap seconds are unpredictable.

> It appears to me that the answer is no. I'm just surprised to
> see the additional shift of an hour shift at 1630 - 1640 and
> 2199-2209.
>
> why?)
>
> ...


These are during daylight savings time:
> <8:00pm Sun Mar 18, 1610>,
> <8:00pm Wed Mar 15, 1620>, 
> <8:00pm Sat Mar 13, 1630>,

These are not during daylight savings time:
> <7:00pm Tue Mar 10, 1640>, 
> <7:00pm Fri Mar 8, 1650>, 
> <7:00pm Mon Mar 5, 1660>, 
> ...
> <7:00pm Wed Nov 10, 2179>, 
> <7:00pm Sat Nov 7, 2189>, 
> <7:00pm Tue Nov 5, 2199>,

These are during daylight savings time:
> <8:00pm Fri Nov 3, 2209>, 
> <8:00pm Mon Nov 1, 2219>, 
> <8:00pm Thu Oct 29, 2229>, 
> ...
>
> My question was 'and does the conversion include leap seconds'. The
> answer appears to be 'no', but the 7pm/8pm conversions seem odd.

The hour differences are because of daylight savings time.

Jay

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.