From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: hpa@transmeta.com
Cc: linux-kernel@vger.rutgers.edu
Subject: Re: GPS Leap Second Scheduled!
Date: Thu, 10 Sep 1998 11:05:38 -0400 [thread overview]
Message-ID: <199809101505.LAA24441@dcl.MIT.EDU> (raw)
In-Reply-To: H. Peter Anvin's message of 10 Sep 1998 01:37:05 GMT, <6t7ag1$trf$1@palladium.transmeta.com>
From: hpa@transmeta.com (H. Peter Anvin)
Date: 10 Sep 1998 01:37:05 GMT
Right. I think the right solution is one I suggested on c.o.l.d.s
recently:
- time_t being a 64-bit signed integer linked to UTC
- struct timespec (and struct timeval, presumably) having an extra
field added:
64-bit seconds field (same as time_t) linked to UTC
32-bit nanosecond field (microsecond for timeval) linked to TAI
32-bit integral TAI-UTC difference
This works, although it would require making a glibc interface change.
But if the ELF symbol versioning works out, perhaps this won't be as big
of an issue.
However, in order to in sync with POSIX.1's definition of how time_t relates to
UTC time, I'd suggest that we make the progression go as follows:
... making the progress go as follows:
tv_sec tv_delta UTC
T-1 N 23:59:59
T N 23:59:60
T N+1 00:00:00
T+1 N+1 00:00:01
(that is, repeat tv_sec == T instead of tv_sec == T-1).
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html
next prev parent reply other threads:[~1998-09-10 12:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <299BBE59294E@rkdvmks1.ngate.uni-regensburg.de>
[not found] ` <98090822315400.00819@soda>
1998-09-09 0:59 ` GPS Leap Second Scheduled! H. Peter Anvin
1998-09-09 8:00 ` Chris Wedgwood
[not found] ` <199809092149.RAA06993@hilfy.ece.cmu.edu>
1998-09-10 1:37 ` H. Peter Anvin
1998-09-10 15:05 ` Theodore Y. Ts'o [this message]
1998-09-12 19:57 ` Feuer
1998-09-09 16:35 ` David Lang
[not found] <19980914165757.A17479@tantalophile.demon.co.uk>
[not found] ` <199809150603.XAA29073@cesium.transmeta.com>
[not found] ` <19980915100729.02790@albireo.ucw.cz>
[not found] ` <35FF1838.6E247F0C@his.com>
1998-09-17 11:51 ` Jan Echternach
1998-09-11 22:49 Ethan O'Connor
[not found] <no.id>
1998-09-10 6:34 ` Jamie Lokier
1998-09-11 6:18 ` Michael Shields
-- strict thread matches above, loose matches on Subject: below --
1998-09-09 20:13 Colin Plumb
1998-09-09 23:45 ` Chris Wedgwood
1998-09-09 23:55 ` Chris Wedgwood
1998-09-10 8:36 ` Rogier Wolff
1998-09-10 17:05 ` Oliver Xymoron
1998-09-10 22:02 ` Ryan Moore
1998-09-09 4:46 Colin Plumb
1998-09-09 19:08 ` Theodore Y. Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199809101505.LAA24441@dcl.MIT.EDU \
--to=tytso@mit.edu \
--cc=hpa@transmeta.com \
--cc=linux-kernel@vger.rutgers.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox