Re^7: Date Time problem.

I think that GMT is the only reasonable way to deal with date/times in complex applications. I may wind up with log files from 5,7 even more different time zones and have to make a report. This is easier if everybody is "talking about the same kind of time". UTC, GMT, Zulu time is time that means the same thing across time zones (and daylight savings time weirdness).

You may think that the US only has 4 time zones, (Pacific, Mountain, Central, Eastern) but there are actually 4 others! http://www.time.gov/ will show the 8 time zones for the US (includes territories and commonwealths).

Russia has 11 time zones. France and England are in different time zones although many Americans would think that this is just "Europe". The Irish folks will get really upset about this!

I strongly recommend the use of GMT for log data date/time stamps. Converting these date/times to a presentation layer is a separate thing. Maybe the guy in France gets a different looking report from the guy in New York,USA. But log the data so that you can easily generate all of these different reports.

Comment on Re^7: Date Time problem.

Replies are listed 'Best First'.
Re^8: Date Time problem. by ikegami (Patriarch) on Sep 05, 2009 at 18:42 UTC
I strongly recommend the use of GMT for log data date/time stamps. Converting these date/times to a presentation layer is a separate thing. I agree. And when the OP searches for the log entries for a certain day, that would be part of the presentation layer. There's a good chance he'd be interested in the log entries for the local date, not the GMT date.	[reply]
Re^9: Date Time problem. by Marshall (Canon) on Sep 08, 2009 at 00:23 UTC
Yes! I most definitely agree! In addition to GMT, I would say also that using date/time format that is ASCII sortable is also a very good idea. `use format like: 2008/01/22 07:00:05 Thu instead of: Thu Jan 22 07:00:05 2008` [download] That way when getting a range of dates from log, you just have to calculate a string for start and one for end then use string compares to extract the sub-range of log messages. Perl is fantastic at string compare. I would add that if the OP is dealing with multiple time zones, he/she will quickly get used to looking at the GMT time. I mean if you are tracking down some problem between NY city and San Francisco, it is easier when both logs have the same idea of "time". It is not that far fetched and actually a good idea to have a clock in your office/cube that is on GMT. Update: I hope that its clear that I meant using GMT solves this 23 hours vs 24 or 25 hours in a local "day" problem.	[reply] [d/l]