I am running command stat -c%y filename on linux system.
Output:
2014-03-08 13:26:29.335545828 -0800
I am not able to understand the last -0800 thing. Anyone have any idea?
-
Time zone, no??– devnullMar 12, 2014 at 12:49
Add a comment
|
2 Answers
The last field is the timezone, as an offset from the UTC timezone.
Example
$ perl -MPOSIX -e 'print strftime("%z", localtime()),"\n"'
-0400
$ perl -MPOSIX -e 'print strftime("%Z", localtime()),"\n"'
EDT
I'm on the east coast of the United States, so I'm 4 hours behind UTC time, you're likely on the west coast, since your 8 hours behind. If you were ahead of UTC time it would show a plus sign (+) instead of a minus (-).
NOTE: Currently we just changed from EST to EDT for day light savings time.
Notice it can differ?
If you start poking around your filesystem you'll likely find some files that were created while your system was in one timezone, while some were created in the other.
$ stat afile.txt ~/.bashrc | grep Mod
Modify: 2014-03-12 03:51:53.986768920 -0400
Modify: 2014-01-17 20:47:54.406548527 -0500
-
I tried on my system $ perl -MPOSIX -e 'print strftime("%z", localtime()),"\n"' -0700 $ perl -MPOSIX -e 'print strftime("%Z", localtime()),"\n"' PDT– cksMar 12, 2014 at 13:07
-
-
Yup that's west coast, pacific. The files were written when you were in PST = Pacific Standard Time, and now you're in day light savings time there too, PDT = Pacific Daylight Savings Time.– slm ♦Mar 12, 2014 at 13:09
-
-
@cks - not to my knowledge, you'd have to calculate it. But the
datecommand can help if you take the times, convert them to epoch seconds, subtract them, and then convert the epoch seconds back to a more human readable format.– slm ♦Mar 12, 2014 at 14:00
It's giving you the offset from UTC. In your example, the time given is 8 hours behind UTC (typically this is right for the US west coast).
