On Wed, 09 Oct 2002 11:04:51 BST, Andrew Hilborne said: > I just wanted to correct this with respect to unix (I know very little about > NTFS.) Unix filesystem inodes store all timestamps in GMT (a.k.a. Zulu time.) > It is user-space library functions which adjust these values for presentation > against the timezone which is currently set for the system. To be very pedantic, the timezone is settable on a per-process basis, using the TZ environment variable. There is usually a system-wide default, but you can certainly have most of your system using 'EST5EDT', but one special-purpose application supporting West Coast users can be running with PST8PDT. On *SOME* Unix variants, you can use a very non-portable hack based on this fact to get yesterday's/last weeks/whatever date: % date Thu Oct 10 10:57:14 EDT 2002 % TZ=EST29EDT date Wed Oct 9 10:57:21 EDT 2002 % date '+%m-%d' 10-10 % TZ=EST30EDT date '+%m-%d' 10-09 The nice thing about this is that on Oct 1, your cron scripts can easily find out that "yesterday" was Sep 30... Forensics-related implications: If a process smashes its environment and the TZ variable goes away or gets corrupted, you may get "odd" times in logfiles. A large offender is the 'syslog' service, which uses the printable timestamp provided *by the process that sent the message*. So you might get things like this: Oct 6 00:00:50 my-host sendmail[3798]: Oct 6 00:00:50 my-host sendmail[3798]: Oct 6 04:01:25 my-host ftpd[71054]: Oct 6 00:03:15 my-host sendmail[59046]: Guess who has an ftpd that trashed the TZ variable? ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
This archive was generated by hypermail 2b30 : Thu Oct 10 2002 - 08:11:04 PDT