bug#16663: emacs/calc/date

bug#16663: emacs/calc/date

[Bart Nielsen]

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

This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgment at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

M-x calc
vx 200
100 -
'3650*24*3600
*
vm t U


(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 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?)


...
     <8:00pm Sun Mar 18, 1610>,
     <8:00pm Wed Mar 15, 1620>,
     <8:00pm Sat Mar 13, 1630>,
     <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>,
     <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.

Thanks

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/usr/local/share/emacs/24.3/etc/DEBUG.


In GNU Emacs 24.3.1 (i686-pc-linux-gnu, GTK+ Version 2.24.22)
 of 2014-02-02 on fc19-home
Windowing system distributor `Fedora Project', version 11.0.11404000
System Description: Fedora release 19 (Schrödinger's Cat)

Configured using:
 `configure '--with-xpm=no' '--with-jpeg=no' '--with-gif=no'
 '--with-tiff=no''

Important settings:
  value of $LANG: en_US.utf8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  display-time-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<escape> x c a C-g <escape> x r e p o r t SPC b u SPC
<return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
make-network-process dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

[-- Attachment #2: Type: text/html, Size: 5745 bytes --]

bug#16663: emacs/calc/date

[Jay Belanger]

> (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

bug#16663: emacs/calc/date

[Steve Allen]

On Wednesday, February 5, 2014 8:03:33 PM UTC-8, Jay Belanger wrote:
> These are during daylight savings time:
> > <8:00pm Sun Mar 18, 1610>,
> > <8:00pm Wed Mar 15, 1620>,
> > <8:00pm Sat Mar 13, 1630>,

> The hour differences are because of daylight savings time.

The notion of daylight saving time in the 17th century should be a
clue that some underlying concept here is very wrong in the calendar
model.

Also note that it was 4 March 1674 ( Julian calendar, Old Style
corresponding to 1675-03-14) that King Charles II appointed John
Flamsteed as the first Astronomer Royal, and the observatory wasn't
built until the next year, so before then GMT wasn't even a thing.

In this and many other cases of computed proleptic dates the only
reasonable interpretation of the time scale is Universal Time (UT, not
UTC).  There have never been leap seconds in Universal Time, for UT is
actually a count of calendar days that can be subdivided into seconds,
not a count of seconds that can be integrated into days.

--
Steve Allen                 <sla@ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165    Lat  +36.99855
1156 High Street            Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

bug#16663: emacs/calc/date

[Jay Belanger]

Steve Allen <sla@ucolick.org> writes:
...
> The notion of daylight saving time in the 17th century should be a
> clue that some underlying concept here is very wrong in the calendar
> model.

For daylight savings time calculation, Calc only differentiates between
before/after 2007.  I think Calendar might do the same.  I don't know
about Calendar, but by default Calc bases its DST adjustments based on the time
zone and whether or not daylight savings time is used at all.  (Each
person could write their own DST function, but that would be a pain.)
I don't know whether or not anything too much more sophisticated can be
done, but I'll look into it after the next Emacs release.  (Perhaps
something like a user configurable "DST begins this year" and "DST ends
this year"; as far as I can tell, the beginning and end years depend on
more than the time zone.)

> In this and many other cases of computed proleptic dates the only
> reasonable interpretation of the time scale is Universal Time (UT, not
> UTC).

Could you be more precise?  From what I've read, UT isn't precisely
defined and UTC is one possible interpretation of it.

Thanks,
Jay

bug#16663: emacs/calc/date

[Steve Allen]

On Thu 2014-02-06T22:52:42 -0600, Jay Belanger hath writ:
> For daylight savings time calculation, Calc only differentiates between
> before/after 2007.  I think Calendar might do the same.  I don't know
> about Calendar, but by default Calc bases its DST adjustments based on the time
> zone and whether or not daylight savings time is used at all.  (Each
> person could write their own DST function, but that would be a pain.)
> I don't know whether or not anything too much more sophisticated can be
> done, but I'll look into it after the next Emacs release.  (Perhaps
> something like a user configurable "DST begins this year" and "DST ends
> this year"; as far as I can tell, the beginning and end years depend on
> more than the time zone.)

So this math is not only limited to being valid on earth, but also
limited to US and Canada subsequent to the 1987 change of the Uniform
Time Act?  That was not clear given the dates being investigated.
I leave all timezone questions to the IANA tz community.

> > In this and many other cases of computed proleptic dates the only
> > reasonable interpretation of the time scale is Universal Time (UT, not
> > UTC).
>
> Could you be more precise?  From what I've read, UT isn't precisely
> defined and UTC is one possible interpretation of it.

For dates prior to atomic chronometers UT is defined more precisely
than the sources of time that were available to most users of civil
time.

For dates after atomic chronometers it becomes necessary to decide
whether the time scale relevant to the problem at hand wants to be
based on counting calendar days of earth rotationand subdividing them
(flavors of UT), or based on counting SI seconds and integrating them
(flavors of atomic time like TAI, GPS), or based on the compromise we
now know as UTC where the duration of the second (SI second of cesium
hyperfine transition) is unrelated to the duration of the day (a mean
solar day of earth rotation).

POSIX chose the first of those three yet called it UTC.

Piles of details about all these time scales are here
http://www.ucolick.org/~sla/leapsecs/timescales.html

--
Steve Allen                 <sla@ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165    Lat  +36.99855
1156 High Street            Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

bug#16663: emacs/calc/date

[Jay Belanger]

> So this math is not only limited to being valid on earth, but also
> limited to US and Canada subsequent to the 1987 change of the Uniform
> Time Act?

The math is good anywhere.  You may not like the interpretation of the
results, though.

>> Could you be more precise?  From what I've read, UT isn't precisely
>> defined and UTC is one possible interpretation of it.
>
> For dates prior to atomic chronometers UT is defined more precisely
> than the sources of time that were available to most users of civil
> time.

Which doesn't tell me what UT is.

> Piles of details about all these time scales are here
> http://www.ucolick.org/~sla/leapsecs/timescales.html

For those that want piles of details; I suppose.  I was wondering which
version of UT you were referring to.

At any rate, nothing will be done until after the next release of
Emacs.  Then I'll check to see how other programs handle DST.  Since the
original bug report didn't report a bug, I'll close this report.

Jay

bug#16663: emacs/calc/date

[Jay Belanger]

> (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 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?)

This was more of a question than a bug.  The question was answered, so
the bug report is being closed.

Jay

bug#16663: emacs/calc/date

[Steve Allen]

On Thu 2014-02-06T23:28:26 -0600, Jay Belanger hath writ:
> > For dates prior to atomic chronometers UT is defined more precisely
> > than the sources of time that were available to most users of civil
> > time.
>
> Which doesn't tell me what UT is.

For most practical purposes UT is GMT.

> > Piles of details about all these time scales are here
> > http://www.ucolick.org/~sla/leapsecs/timescales.html
>
> For those that want piles of details; I suppose.  I was wondering which
> version of UT you were referring to.

The different forms of UT coincidentally happened to be defined during
the same meeting which announced the results from the first cesium
atomic chronometer.
Before cesium atomic there was just UT.
After cesium atomic there was UT0, UT1, UT2, but it hardly matters.
Until about 1972 there were fingers-on-hands-countably-few sites with
chronometers capable of noting the difference between flavors of UT.

--
Steve Allen                 <sla@ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165    Lat  +36.99855
1156 High Street            Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m