2

I have searched, but can't find the right terminology.

For example, if today was Friday, and a file was modified on Wednesday, then when I change the system time to Saturday, does the file's mtime remain Wednesday, or does it change to Thursday?

How does this apply to other operating systems?

Improve this question
5
  • Under Linux it should remain with the date you created/modified it, despite the fact you may have changed you system's time. In certain cases you could get warnings that the file was modified in the future -- for example when compiling a kernel.
    – carlspring
    Jun 20, 2013 at 20:06
  • 2
    I think pondering the implications of file timestamps not being absolute times (regardless of timezone) would quickly lead to the conclusion that timestamps can't be stored as relative times - that would mean that, on every tick of the clock, the system would have to update every relative time stamp stored on your disk (again)...
    – twalberg
    Jun 20, 2013 at 20:14
  • @twalberg - I had to read the question again to understand your response. I thought the OP was talking about time zones. I think your interpretation is about the clock actually being updated, either through its own ticking away, or being manually adjusted. So yes, that makes sense too. HOWEVER - this is still not a good question for S.O.
    – Matt Johnson-Pint
    Jun 20, 2013 at 20:18
  • @MattJohnson Agreed... It's also possible I read something into the question...
    – twalberg
    Jun 20, 2013 at 20:26
  • @MattJohnson Thank you for moving this to the correct forum. This is only my second question. I have a database application that depends on the creation time of files and I wasn't sure if the time on the server was correct. I wanted to know if there were implications in changing the system time, but it really wouldn't make sense to store the time in a relative manner. It was just one of those things that should seem obvious to me, but could cause really big problems if I was wrong.
    – aomimezura
    Jun 20, 2013 at 20:47

2 Answers 2

Reset to default
2

System time is a clock maintained by the kernel. When you update a file the current mtime of the file is updated to the current kernel time. Filetimes are in UTC, as seconds into the epoch (from Jan 1 1970). (this is not exactly how windows does it - this is Linux/UNIX)

So you can fiddle with system time and set it backwards. You can get future dates on files, --- some few older filesystems don't "like" this. So changing the system clock does not alter in anyway existing filetimes. Only using commands that update filetimes like touch or actually alter the file or file metadata, do that.

You can also get future dates on files with by abusing system calls utime() and commands like touch.

This is a 32bit system and the touch command caused problems by using a date beyond 32bit date arithmetic. The number of UTC seconds was too big.

jmcnama@SNEDAP03 ~> ls -l t.lis
-rw-r--r--   1 jmcnama  other         68 Jun  4 10:17 t.lis


jmcnama@SNEDAP03 ~> touch -t 2099010100 t.lis
jmcnama@SNEDAP03 ~> ls -l t.lis
-rw-r--r--   1 jmcnama  other         68 Mar  1  2028 t.lis
Improve this answer
1

Please provide more details about the platform you are using, specifically the operating system and file system.

With regards to Linux, it's most likely going to be stored as a UTC timestamp (see Jim's answer).

On Windows, if you are using NTFS then you are going to find similar behavior as Linux in that the timestamp is based on UTC. But they use different epoch times. When stored as an integer on Linux, 0 means 1/1/1970. But on Windows, 0 means 1/1/1601.

If you are using FAT or FAT32 on Windows, then beware that file times are not based on UTC, but on the local time zone of the computer that recorded it. That means there can be ambiguity around daylight saving time transition dates, and if you change your time zone, or bring files to a computer in a different time zone (perhaps over a FAT32-formatted USB key, for example) that the times will be interpreted as if they were in that time zone.

You can read more about Windows specifics here.

Either way, the ticking of the clock, or the manual adjustment of the clock, will not affect timestamps of recorded files in any way. It will only affect timestamps of new files.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .