Are you sure about that? When atime alone is updated it is equivalent to logging the last time a file was read, which is not interesting to Make, at least. Make only wants to know when a file was last written to, which is mtime. A look at GNU Make confirms that it uses mtime, and not atime (it uses ctime for some #ifdef Windows operations, for some reason). SCCS I'm not sure about - I only have a copy of an old Tahoe 4.3BSD sccs.c, and I can't find any time field access at all.
The one use for atime I'm aware of (by applications) is for backups, backup systems will sometimes use atime to check if a particular file has been read already. But I have a hard time actually finding source which use atime..

-Tor

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I was certainly thinking the same thing; one second time-stamp resolution could be inadequate in some cases. It could be argued that any reasonable resolution could become inadequate in extreme situations, but it couldn't hurt to borrow a few of those "thousands-of-years" bits from the 64-bit stamp and move them to the other side of the scale, like "thousandths-of-seconds", where they could actually convey important information for the here-and-now.

Mike B.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I've been following along this topic. Found it very informative.

I use a millisecond interrupt in my system, but now I see it'd be better to use 1024 Hz. That way the time in seconds could be determined with a simple right shift of ten bits. This would give me 54 usable bits for system time - it could be truncated to 48 bits. I use the millisecond interrupt for timing some I/O devices. My system also uses a 100Hz interrupt for task switching.

Being hardware oriented, it seems to me that updating the system time is a fairly common task. It could very easily be done with hardware as part of a timekeeping device, saving some cycles in an interrupt routine.

_________________
http://www.finitron.ca

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

TBH I prefer the POSIX approach of two binary fields: one for seconds, and one for a power-of-ten fractions of seconds. Using 1024Hz or another power-of-two fraction (or indeed 60Hz or something related) feels like it's heading for conversion difficulties - userspace is likely to want a decimal view of time, but of course binary numbers feel better in the kernel. Two binary fields seems good to me: not too difficult to increment the time or to subtract times, not too difficult to convert to userspace.

Over on vintage-computer I suggested using Planck time as the tick.. and epoch time would be the Big Bang, of course (~13.75 billion years ago). It seems 202 bits would be enough to cover from epoch to about now, and with 256 bits you would be covered until more than three hundred billion billion years into the future, which must (for once) be enough for everybody. The good thing is that you won't need a signed integer, unsigned will do fine according to common theory. And actual resolution can of course be implementation dependent, just as now - e.g. as with the nanosleep() function, which rarely has actual nano second resolution. This would be the final computer time method, never to be superseeded. At least as far as the resolution is concerned. If there is a change of theory you could always go to signed integer (suggesting that there was actually something like physical time before the Big Bang), and still have way more than enough bits to cover for the expected lifetime of the universe. According to some. If, on the other hand, the lifetime is 10^10^56 years (according to another theory) then a revision may be needed, but at that time they can move to 512 or 1024 bits for sure.
256 bits isn't really that much more than the current 64 bits of the Linux kernel, so this isn't as silly as it may look..

-Tor

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

There's another possible tactic, which I'm sure I've read about somewhere. The fractional part of the time spec is incremented at least every time it's read, which gives a kind of transaction count. No matter how fast your filesystem or database accesses occur, each one gets a unique and biggest-yet timestamp. Might take a little care to account for the reported time getting ahead of the actual time, but that seems possible so long as the average rate of reads isn't greater than the incremental precision.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

You need to know the true time, and the last issued timestamp. If the time has advanced since last request when it's requested, you issue it and update the last issued. If it hasn't, because you've been asked the time twice in succession, you increment the last issued timestamp and issue that. So, in a sense, you keep two copies of the time, which both move forward.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Sounds good, but you'd need to be sure that such a small increase has actually changed the value... looks like it's a 14-digit capable system so that should be ok.