Date: Wed, 19 Aug 1998 17:49:42 -0500 (CDT) From: Joel Ray Holveck <joelh@gnu.org> To: drosih@rpi.edu Cc: peter.jeremy@auss2.alcatel.com.au, hackers@FreeBSD.ORG Subject: Re: proposal to not change time_t Message-ID: <199808192249.RAA14808@detlev.UUCP> In-Reply-To: <v04011704b200cd235416@[128.113.24.147]> (message from Garance A Drosihn on Wed, 19 Aug 1998 14:57:20 -0400) References: <v04011704b200cd235416@[128.113.24.147]>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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. I still haven't heard why this is a useful filesystem addition. (Please no flame wars!) > 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. And while we're at it, I'd like a pony. > 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. Ugh. At least make it a multiple of 8 bits, ie 255ths of a second. Happy hacking, joelh -- Joel Ray Holveck - joelh@gnu.org - http://www.wp.com/piquan Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped 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?199808192249.RAA14808>