New pre-SRFI: Modern date and time library
Daphne Preston-Kendal
(09 Nov 2024 09:48 UTC)
|
Re: New pre-SRFI: Modern date and time library
Alex Shinn
(09 Nov 2024 11:49 UTC)
|
Re: New pre-SRFI: Modern date and time library
Daphne Preston-Kendal
(10 Nov 2024 19:52 UTC)
|
Re: New pre-SRFI: Modern date and time library
John Cowan
(11 Nov 2024 03:49 UTC)
|
Re: New pre-SRFI: Modern date and time library
Alex Shinn
(11 Nov 2024 04:33 UTC)
|
Re: New pre-SRFI: Modern date and time library
Arthur A. Gleckler
(09 Nov 2024 17:36 UTC)
|
Re: New pre-SRFI: Modern date and time library
Pierpaolo Bernardi
(10 Nov 2024 00:56 UTC)
|
Re: New pre-SRFI: Modern date and time library
Arthur A. Gleckler
(10 Nov 2024 04:28 UTC)
|
Re: New pre-SRFI: Modern date and time library
Pierpaolo Bernardi
(10 Nov 2024 05:06 UTC)
|
Re: New pre-SRFI: Modern date and time library
Daphne Preston-Kendal
(10 Nov 2024 10:11 UTC)
|
Re: New pre-SRFI: Modern date and time library
Pierpaolo Bernardi
(10 Nov 2024 15:02 UTC)
|
Re: New pre-SRFI: Modern date and time library
Daphne Preston-Kendal
(10 Nov 2024 15:37 UTC)
|
Re: New pre-SRFI: Modern date and time library
Lassi Kortela
(10 Nov 2024 15:57 UTC)
|
Re: New pre-SRFI: Modern date and time library
Alex Shinn
(11 Nov 2024 04:43 UTC)
|
Re: New pre-SRFI: Modern date and time library
Daphne Preston-Kendal
(10 Nov 2024 10:19 UTC)
|
Re: New pre-SRFI: Modern date and time library
Daphne Preston-Kendal
(03 Jan 2025 12:43 UTC)
|
Re: New pre-SRFI: Modern date and time library
Marc Nieper-Wißkirchen
(03 Jan 2025 14:08 UTC)
|
Re: New pre-SRFI: Modern date and time library Daphne Preston-Kendal (03 Jan 2025 14:56 UTC)
|
Re: New pre-SRFI: Modern date and time library
Daphne Preston-Kendal
(03 Jan 2025 15:03 UTC)
|
Re: New pre-SRFI: Modern date and time library
Marc Nieper-Wißkirchen
(03 Jan 2025 15:26 UTC)
|
Re: New pre-SRFI: Modern date and time library
Marc Nieper-Wißkirchen
(03 Jan 2025 15:22 UTC)
|
Re: New pre-SRFI: Modern date and time library
Daphne Preston-Kendal
(03 Jan 2025 20:45 UTC)
|
Re: New pre-SRFI: Modern date and time library
Alex Shinn
(05 Jan 2025 23:10 UTC)
|
Re: New pre-SRFI: Modern date and time library
John Cowan
(06 Jan 2025 01:12 UTC)
|
On 3 Jan 2025, at 15:08, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote: > I may have more comments soon, but here is one about the initial > definitions as this proposed SRFI does want to do everything right if > possible (which is a good thing IMO): > > Reading the definition of the TAI calendar, it can sound as if there > were an absolute time (otherwise, the phrase "every 86,400 SI seconds" > would not make sense). However, atomic clocks are precise enough to > detect the derivations of Newtonian mechanics from special and general > relativity. As there is no god-given absolute clock one has to take an > arbitrary clock as a reference. A suitable reference is precisely the > TAI clock, measuring seconds since the event that is called "1 January > 1958" in the TAI calendar. Note that the phrase "at midnight on 1 > January 1958" does not make sense before the definition of any > calendar (or, at least, has the danger of being a self-referential > definition). > > With the TAI clock set as a reference, the TAI and the UTC calendar > can then be derived through simple arithmetic. I’m not sure I understand. As a practical simplification, this SRFI (like many timekeeping applications) assumes that everything on planet Earth can be seen as having a common frame of reference. This is not true, but it’s usually considered close enough to the truth for most purposes. I agree there’s a risk of formal self-reference, but I wonder if you’re actually getting at a problem with the wording I was already concerned about, but had thought about in different terms than you seem to be using. The SRFI is not trying to do anything totally new, but rather merely to try to formalize in some useful way the informal notion of date and time for TAI as it’s already used, namely the notion that TAI (which ‘just ticks’, as John says) can be treated as if it were like UTC-based civil time, but going 37 seconds fast. Another formalization of this sort of idea is found in GPS time, which uses a count of weeks and a count of the number of seconds into the week, rather than the day-based version I use here. If you can suggest a better way to make that formalization, or some other way to relate the pre-SRFI’s calendar-system-independent notion of a ‘date’ to points in the TAI clock’s timescale, I would very much welcome it. Perhaps this is also the problem Pierpaolo Bernardi was concerned about … Daphne