Date: Sat, 15 Aug 1998 12:04:45 +0930 From: Greg Lehey <grog@lemis.com> To: Tim Vanderhoek <ac199@hwcn.org>, Matthew Hunt <mph@pobox.com>, Ivan Brawley <brawley@camtech.com.au>, hackers@FreeBSD.ORG Subject: Re: 64-bit time_t Message-ID: <19980815120445.C21662@lemis.com> In-Reply-To: <19980814114525.B4001@zappo>; from Tim Vanderhoek on Fri, Aug 14, 1998 at 11:45:25AM -0400 References: <199808131721.KAA00864@antipodes.cdrom.com> <199808140040.KAA14156@mad.ct> <19980814000605.A25012@astro.psu.edu> <19980814135919.U1921@freebie.lemis.com> <19980814114525.B4001@zappo>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, 14 August 1998 at 11:45:25 -0400, Tim Vanderhoek wrote:
> On Fri, Aug 14, 1998 at 01:59:19PM +0930, Greg Lehey wrote:
>>
>> More to the point, time_t *can* be used to represent BE (Before Epoch)
>> dates. Make it unsigned and you break that.
>
> "time_t is a format for the system current time. As such, you're
> abusing it mightily if you expect it to be a general-purpose time
> value." - Mike Smith <mike@smith.net.au>
Yes, I read that. That doesn't mean that I agree with it. I don't.
But even if it were true, it wouldn't be a valid argument.
One problem UNIX has is that there is no standardized format for
representing times. There is no sensible reason to use one format for
representing system times, one (inconvenient) format for representing
times more accurately (down to only 1 microsecond, when it could have
been down to a nanosecond), and one format broken down into
representations of the individual units of time. None are of any use
when I want to know "How many seconds has it been since my grandfather
was born?". time_t *will* answer the question "How many seconds has
it been since my father was born?".
Moving to 64 bits creates a number of opportunities to improve this
situation:
1. Make it an extended time_t and you can measure time from before
the big bang until after the predicted collapse of the universe.
2. Make it a merged struct timeval (i.e. tv_usec + 1000000 * tv_sec)
and you have a *useful* replacement for both time_t and struct
timeval which will still measure time from before the beginning of
recorded history to at least the release of FreeBSD 3.0.
3. Make it (2) * 1000 and base it on the year 2000 (just to rub it
in) and you can measure time to the nearest nanosecond from 1708
to 2292.
Of course, for this to make *any* sense at all, it should be a format
that everybody accepts. Otherwise we've just made the matter worse.
Greg
--
See complete headers for address, home page and phone numbers
finger grog@lemis.com for PGP public key
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980815120445.C21662>