Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have some files on server with the date several months ago, but invisible for find -mtime 7 search.

When I list them as ls -l they look perfectly normal

-rw-r--r-- 1 root root    347253 Jun 12 16:26 pedia_main.2010-06-12-04-25-02.sql.gz
-rw-r--r-- 1 root root 490144578 Nov 24 16:26 gsmforum_main.2010-11-24-04-25-02.sql.gz

The top file is invisible to "find . -mtime 1", but the botton one - is visible.

I almost smashed by head by the wall trying to understand why. I tried some random things and came across ls --full-time command. And it shows, that these two are somehow a little bit different

-rw-r--r-- 1 root root    347253 2010-06-12 16:26:20.000000000 +0400 pedia_main.2010-06-12-04-25-02.sql.gz
-rw-r--r-- 1 root root 490144578 2010-11-24 16:26:12.000000000 +0300 gsmforum_main.2010-11-24-04-25-02.sql.gz

The date seem to be ok, bit one has +0400 as a timezone, and another one is +0300. How come find fails to find the ones with +0400?

OS is CentOS 5.5 Final with latest updates, ls version is (GNU coreutils) 5.97

Also, the thing is that I don't understand where this "timezone" of the file is stored. inode does not have any extra attributes to store them it seems. The FS on server is ext4.

share|improve this question
2  
The difference in timezone offset is due to the fact that one date is during Daylight Saving Time for your time zone and the other is not. Since UTC doesn't shift and your time zone does, the offset from UTC changes. The time zone is not stored with the file. The offset is calculated when the directory entry is output. –  Dennis Williamson Dec 1 '10 at 14:49

4 Answers 4

up vote 8 down vote accepted

It's possible that the timzeone issue is a red herring.

find . -mtime 7 

should find files that are exactly seven days old ("seven" meaning between 7.000 and 7.999 days, give or take, and "old" meaning "since last modification"). If you want files that are more than seven days old, which judging by the date on your first file (June 2010) you do, try

find . -mtime +7

I agree with you about the apparent timezone being odd, but I think it's explicable. man stat is clear that a time_t is stored, as Sean R says below. What ls is doing is displaying that as a local time, and it's being kind enough to take account of local daylight-saving conventions when it does so.

My system is the same: file times which happen to fall in Mar-Oct are shown with a +0100 timezone while those which fall in Oct-Mar are shown with a +0000 timezone, not because this is stored in the file system but because the timezone file tells my system that in June, when I touched the file, I would have done it at a time that I thought was 8am, not it-would-be-7am-if-it-were-winter. ls is kind enough, when displaying times that happen to be in summer, to show them as they would have appeared in summer, that's all.

If you can find any timezones in your ls output that aren't either summer or winter according to your local convention, then I'm wrong - but I can't find any on my system.

share|improve this answer
    
Thanks! But timezone question is still interesting since I don't see how timezone settings can be stored in ext4 on per-file basis. –  FractalizeR Dec 1 '10 at 13:36
    
See my modified answer above. –  MadHatter Dec 2 '10 at 9:07

With find, -mtime works in 24 hour periods so

-mtime 0 or -mtime -1 mean today
-mtime 3 would mean 3 days old
-mtime +1 means greater than one day old 
-mtime -7 means less than 7 days old
share|improve this answer
    
I know. Actually, I used mtime 7 variant. But it doesn't work also despite the date is much in the past. –  FractalizeR Dec 1 '10 at 13:22
    
to get find to show your older file you would need to have a + in your time spec e.g -mtime +7 which will find all files older than 7 days. –  Iain Dec 1 '10 at 15:27
    
Yea, thanks, I see now. –  FractalizeR Dec 1 '10 at 19:29

To explain the timezone portion of it a bit more (the "mtime" discussion is handled by other comments)...

Date and times are stored on files as seconds since midnight January 1, 1970, UTC. Meaning there is no time-zone associated with them. Programs then use the system timezone setting in /etc/timezone, unless overridden by the "TZ" environment variable, to display that time in the local timezone:

chats:/tmp$ touch foo
chats:/tmp$ ls -l foo
-rw-r--r-- 1 jafo jafo 0 Dec  1 06:14 foo
chats:/tmp$ TZ=GMT ls -l foo          
-rw-r--r-- 1 jafo jafo 0 Dec  1 13:14 foo
chats:/tmp$ 

Note in the last line it is showing 1:14pm, and in the output above it, where I am using my default timezone of US Mountain time (GMT-0700) it is showing 6:14am. The difference is the second "ls" I set the TZ environment variable to GMT.

You may want to use "stat" to examine all the time/dates associated with files as well.

share|improve this answer
    
I still don't see, how this allows two different files in the same ls listing to have different timezone data in mtime attribute. –  FractalizeR Dec 1 '10 at 13:27
    
The FILES do NOT. It is the users who have the timezone data. All times are stored as I mentioned: seconds since Jan 1 1970 midnight. –  Sean Reifschneider Dec 1 '10 at 18:57
    
I've got an answer on another forum - different GMTs are due to different file dates. In June it's still +3, in November it becomes +4. So, no magic here also ;) Thanks. –  FractalizeR Dec 1 '10 at 19:30

In addition to the above, I often use the following:

find -mtime -7 -daystart 

That tells find to find files that are up to (7 * 24) hours old from the beginning of today.

share|improve this answer

Your Answer

 
discard

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.