Page 2 of 2
Re: Future time epoch and floating point time stamps
Posted: Fri Mar 24, 2023 2:50 pm
by AndrewAPrice
SeaLiteral wrote:[Edit: I do wonder if computers in the future might have more precise timers making nanosecond timestamps accurate and possibly even justifying having such timestamps in a filesystem. Then again, I don't see a need to implement UTF-64 at this time.]
The time format used internally for profiling and kernel scheduling can be different from those used for other purposes, such as file timetamps, an astrology simulator, a geneology database, etc. Second precision is likely good enough for file timestamps. Day precision is likely good enough for geneology records. Millisecond precision is likely good enough for for kernel scheduling. Nanosecond precision is likely good enough for profiling code.
e.g. If your kernel kept a number of nanoseconds since boot as an unsigned 64-bit integer, it would take 292 years for it to roll over. Your computer is likely to have rebooted by then.
Re: Future time epoch and floating point time stamps
Posted: Fri Mar 24, 2023 6:58 pm
by nullplan
SeaLiteral wrote:When I get to implementing EXT-2, I might consider using the OS-specific values to extend the range. Those only exist per inode, so for things like "last mount time" I'll have to just have to consider the times there ambiguous. But I can think of at least three features I want to add before I add a filesystem, and I think the first filesystem I add will probably be USTAR (which seems to use 36-bit timestamps, which considering they're whole seconds would give it a millennium or so before it rolls over, which I hope is enough for me to implement another filesystem).
But in the long run I kinda want to try rolling my own filesystem, just like I kinda want to try rolling my own bootloader sometime. But I figured using a few existing things until I get my own replacements working seemed like a good idea. I just have to hope I've implemented EXT-2 before 2038 so I don't have to initially be making disk images with tools that don't support encoding the times at which I'm using them.
I'd suggest using the same extensions as Linux for those times, so you already have a lot of tool support. It requires the inodes to be 256 bytes in size instead of 128, and the way it was saved was kinda funky, but it does allow for long timestamps. Not sure how it works with the timestamp in the superblock; that may be a superblock extension.