[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22034: time-utc->date shows bogus zone-dependent leap second
From: |
Mark H Weaver |
Subject: |
bug#22034: time-utc->date shows bogus zone-dependent leap second |
Date: |
Mon, 29 Oct 2018 03:16:19 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Hi John,
John Cowan <address@hidden> writes:
> On Sun, Oct 28, 2018 at 4:40 PM Mark H Weaver <address@hidden> wrote:
>
> The difference between the two measuring tapes is that they assign
> different numbers to the markings, and moreover that the UTC analogue
> has a small handful of places where two adjacent markings have the same
> number assigned, and all subsequent numbers are shifted by 1.
>
> Now I think you are entirely right here, modulo a single term: what you are
> calling "UTC", I call (and I think correctly), "Posix". It is Posix time that
> has two identical adjacent markings.
>
> 126230400 |------------
> 126230400 |------------
>
> The numbers here are not UTC seconds since the Epoch, but Posix seconds
> since the Epoch.
Here's a more detailed display of the same leap second that I chose for
my example, which you quoted above:
+-----------------------------------------------------------+
| TAI seconds UTC seconds |
| since since |
| midnight UTC midnight UTC |
| 1 Jan 1970 1 Jan 1970 Result of 'time-tai->date'|
|-----------------------------------------------------------|
|$2 = ((126230410 126230398 "1973-12-31T23:59:58Z") |
| (126230411 126230399 "1973-12-31T23:59:59Z") |
| (126230412 126230400 "1973-12-31T23:59:60Z") |
| (126230413 126230400 "1974-01-01T00:00:00Z") |
| (126230414 126230401 "1974-01-01T00:00:01Z")) |
+-----------------------------------------------------------+
The table above illustrates my understanding of the relationship between
"TAI seconds since midnight UTC on 1 Jan 1970", "UTC seconds since
midnight UTC on 1 Jan 1970" and the date object expressed in UTC. See
my previous email for the code to produce the table above using SRFI-19.
If I understand correctly, based on your last sentence that I quoted
above, you believe that the numbers I've given in the second column are
not UTC seconds since the epoch, and that there is confusion here
between UTC seconds and Posix seconds.
Can you please be more concrete and tell me what numbers you think
should be in the second column, to properly reflect the column heading?
I'm not asking for a prose description, but for the actual numbers.
If the table above is incorrect, then it would be good to report the
problem to the SRFI-19 mailing list, because the current SRFI-19
reference implementation produces the same table.
Thanks,
Mark
- bug#22034: time-utc->date shows bogus zone-dependent leap second, Mark H Weaver, 2018/10/20
- bug#22034: time-utc->date shows bogus zone-dependent leap second, John Cowan, 2018/10/21
- bug#22034: time-utc->date shows bogus zone-dependent leap second, Mark H Weaver, 2018/10/22
- bug#22034: time-utc->date shows bogus zone-dependent leap second, John Cowan, 2018/10/25
- bug#22034: time-utc->date shows bogus zone-dependent leap second, Mark H Weaver, 2018/10/28
- bug#22034: time-utc->date shows bogus zone-dependent leap second, John Cowan, 2018/10/28
- bug#22034: time-utc->date shows bogus zone-dependent leap second,
Mark H Weaver <=
- bug#22034: time-utc->date shows bogus zone-dependent leap second, Mark H Weaver, 2018/10/29
- bug#22034: time-utc->date shows bogus zone-dependent leap second, John Cowan, 2018/10/29
- bug#22034: time-utc->date shows bogus zone-dependent leap second, Mark H Weaver, 2018/10/29