One problem with the daylight savings is that they mess with reporting tools that use timestamps. I guess an application could be configured to log UTC instead of local time, but that's not always doable. Also, if you have servers in several different timezones, it's better if all systems follow the same clock.
So, I'm thinking it's perhaps better if I just use ZONE="UTC" on all systems. These are the steps I can think of so far:
- make sure the BIOS clock is set to UTC - run timeconfig and make sure "System Clock uses UTC" is checked - cp /usr/share/zoneinfo/UTC /etc/localtime - edit /etc/sysconfig/clock and set ZONE="UTC" - reboot
Voila - instant UTC clock. Never need to worry about daylight savings again.
Anybody can think of any problems with: - the procedure I described? - the simple fact of using the "true" UTC timezone?
On Thu, Mar 08, 2007 at 12:04:03PM -0800, Florin Andrei wrote:
- make sure the BIOS clock is set to UTC
- run timeconfig and make sure "System Clock uses UTC" is checked
The above aren't even necessary if your local time is also UTC.
Anybody can think of any problems with:
- the procedure I described?
- the simple fact of using the "true" UTC timezone?
You might accidentally be eight hours early for appointments?
Matthew Miller wrote:
On Thu, Mar 08, 2007 at 12:04:03PM -0800, Florin Andrei wrote:
Anybody can think of any problems with:
- the procedure I described?
- the simple fact of using the "true" UTC timezone?
You might accidentally be eight hours early for appointments?
Well, OK, let's eliminate the email/calendar stuff from the discussion.
Just Web servers, app servers, things like that. The data that's served by those machines is not dependent on the time zone.
On Thu, Mar 08, 2007 at 12:34:29PM -0800, Florin Andrei wrote:
You might accidentally be eight hours early for appointments?
Well, OK, let's eliminate the email/calendar stuff from the discussion. Just Web servers, app servers, things like that. The data that's served by those machines is not dependent on the time zone.
Considering that web servers apparently work fine in Greenwich, I don't think there's any real problems. I've thought about doing the same thing for similar reasons.
On Thu, Mar 08, 2007 at 03:37:52PM -0500, Matthew Miller wrote:
Considering that web servers apparently work fine in Greenwich, I don't think there's any real problems. I've thought about doing the same thing for similar reasons.
My first job was in a shipping company and we had offices around the world, and also Unix machines onboard the ships (fun!). We set every machine to UTC (which confused the London people when they didn't go to summer time; "the clock is an hour slow". Other timezones didn't care; they were used to the clock being wrong).
The one gotcha is to move any cron jobs to idle times. Midnight GMT might be peak activity on your webserver so you don't want overnight jobs to kick off then!
Stephen Harris wrote:
The one gotcha is to move any cron jobs to idle times. Midnight GMT might be peak activity on your webserver so you don't want overnight jobs to kick off then!
Good idea.
One other thing is that, when reading logs, for now people are used to see timestamps in the local time zone. But, since the logs that actually matter will be in a database, I guess I can always add a translation layer to the PHP page that will display those logs and optionally convert the timestamps to local time on-the-fly, if that's what the user wants.
Florin Andrei wrote:
Just Web servers, app servers, things like that. The data that's served by those machines is not dependent on the time zone.
All times in unix styles systems should be in UTC/GMT. Timezone is just used for displaying the local time. Applications should always use UTC/GMT internally, like database system transaction logs etc. Changing timezone should be transparent and should not affect the system at all.
That is the way it is supposed to be anyway :)
Florin Andrei spake the following on 3/8/2007 12:04 PM:
One problem with the daylight savings is that they mess with reporting tools that use timestamps. I guess an application could be configured to log UTC instead of local time, but that's not always doable. Also, if you have servers in several different timezones, it's better if all systems follow the same clock.
So, I'm thinking it's perhaps better if I just use ZONE="UTC" on all systems. These are the steps I can think of so far:
- make sure the BIOS clock is set to UTC
- run timeconfig and make sure "System Clock uses UTC" is checked
- cp /usr/share/zoneinfo/UTC /etc/localtime
- edit /etc/sysconfig/clock and set ZONE="UTC"
- reboot
Voila - instant UTC clock. Never need to worry about daylight savings again.
Anybody can think of any problems with:
- the procedure I described?
- the simple fact of using the "true" UTC timezone?
System spikes caused by logrotation happening in the middle of the workday? Not a real problem, but the first one I could think of.
On Thu, 8 Mar 2007, Scott Silva wrote:
Voila - instant UTC clock. Never need to worry about daylight savings again.
Anybody can think of any problems with:
- the procedure I described?
- the simple fact of using the "true" UTC timezone?
System spikes caused by logrotation happening in the middle of the workday? Not a real problem, but the first one I could think of.
Solving that problem is as easy as adjusting the hour at which /usr/bin/run-parts is launched:
$EDITOR /etc/crontab
-
Florin Andrei -
Matthew Miller -
Morten Torstensen -
Paul Heinlein -
Scott Silva -
Stephen Harris