Liste des Groupes | Revenir à cl c |
[snip]BGB <cr88192@gmail.com> writes:
On 4/15/2025 9:10 AM, Scott Lurndal wrote:BGB <cr88192@gmail.com> writes:On 4/14/2025 5:33 PM, Lawrence D'Oliveiro wrote:On Mon, 14 Apr 2025 13:36:07 -0500, BGB wrote:
>On 4/14/2025 12:40 PM, candycanearter07 wrote:
>Technically, it depends on the timezone:Relative to what epoch?>
>
Probably still Jan 1 1970...
Technically, it does not.
>
POSIX defines the epoch as follows:
>
Historically, the origin of UNIX system time was referred to as
"00:00:00 GMT, January 1, 1970". Greenwich Mean Time is actually not
a term acknowledged by the international standards community;
therefore, this term, "Epoch", is used to abbreviate the reference
to the actual standard, Coordinated Universal Time.
>
The epoch is a specified moment in time. That moment can be
expressed as midnight UTC Jan 1 1970, as 4PM PST Dec 31 1969,
or (time_t)0. GMT/UTC is just a convenient way to specify it.
>$ date --date="@0"
Wed Dec 31 16:00:00 PST 1969
Yes, the date command by default uses the local time zone by default.
>Well, and however much error there is from decades worth of leap>
seconds, etc...
Yes, leap seconds are an issue (and would be for any of the proposed
alternatives).
>But, yeah, better if one had a notion of time that merely measured>
absolute seconds since the epoch without any particular ties to the
Earth's rotation or orbit around the sun. Whether or not its "date"
matches exactly with the official Calendar date being secondary.
That's called TAI; it ignores leap seconds. See clock_gettime()
(defined by POSIX, not by ISO C). (Not all systems accurately record
the number of leap seconds, currently 37.)
>
Most systems don't use TAI for the system clock, because matching civil
time is generally considered more important than counting leap seconds.
>
[...]
Les messages affichés proviennent d'usenet.