Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

migrated from Jun 20 '13 at 20:38

This question came from our site for professional and enthusiast programmers.

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 '13 at 20:06
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 '13 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 Jun 20 '13 at 20:18
@MattJohnson Agreed... It's also possible I read something into the question... – twalberg Jun 20 '13 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 '13 at 20:47

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
share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.