Date: Wed, 19 Aug 1998 14:57:20 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au>, hackers@FreeBSD.ORG Subject: Re: proposal to not change time_t Message-ID: <v04011704b200cd235416@[128.113.24.147]> In-Reply-To: <98Aug19.105412est.40322@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:54 AM +1000 8/19/98, Peter Jeremy wrote: > Alternatively, do we really need nsec timestamps in inodes? We could > store a 64-bit seconds timestamp in the inode and have SYS_stat() map > it to a struct timespec with a zero tv_nsec. (Less convenient options > which address the make's difficulties in chronologically ordering > rapidly created files would be to use a 64-bit fixed-point number > with 8, 16 or even 24 fractional bits). I do think it's useful to have time resolution be better than 1 second. At the same time, I would like to put off newfs'ing systems for a new format as long as possible, while still solving the 2039 issue. We currently have the 32-bit time_t, and the 32 bits stolen to give us nanosecond timestamps. Just how weird would it be to make it a 64-bit time field which was 1024'ths of a second? To get a valid time_t (in seconds) you'd have to shift the value a few bits, and you could provide that value in a 64-bit number if you want. It just seems weird to say we need all 64 bits for time_t. Changing time_t to be 48 or 56 bits would put off any problems for a pretty significant number of years, and yet provide us with better time resolution without the spectre of newfs-ing disks. (I just picked 1024'ths of a second because I have a vague recollection of IBM using that for it's STCK (store clock) instruction, but my memory might be playing tricks on me there...) --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute 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?v04011704b200cd235416>