FAQ
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?

Search Discussions

  • Matthew Miller at Mar 8, 2007 at 8:07 pm

    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 mattdm@mattdm.org <http://mattdm.org/>
    Boston University Linux ------> <http://linux.bu.edu/>
  • Florin Andrei at Mar 8, 2007 at 8:34 pm

    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.
  • Matthew Miller at Mar 8, 2007 at 8:37 pm

    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.

    --
    Matthew Miller mattdm@mattdm.org <http://mattdm.org/>
    Boston University Linux ------> <http://linux.bu.edu/>
  • Stephen Harris at Mar 8, 2007 at 8:50 pm

    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!

    --

    rgds
    Stephen
  • Florin Andrei at Mar 9, 2007 at 1:10 am

    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.
  • Morten Torstensen at Mar 10, 2007 at 1:12 pm

    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 :)

    --

    //Morten Torstensen
    //Email: morten@mortent.org
    //IM: Cartoon@jabber.no morten.torstensen@gmail.com

    And if it turns out that there is a God, I don't believe that he is evil.
    The worst that can be said is that he's an underachiever.
  • Scott Silva at Mar 8, 2007 at 9:32 pm

    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.

    --

    MailScanner is like deodorant...
    You hope everybody uses it, and
    you notice quickly if they don't!!!!
  • Paul Heinlein at Mar 8, 2007 at 9:52 pm

    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

    --
    Paul "$EDITOR == vim" Heinlein
  • Stephen Harris at Mar 9, 2007 at 1:18 am

    Florin Andrei wrote:
    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.
    But then you've just moved the DST issue into your application and not
    really solved much at all :-)

    --

    rgds
    Stephen
  • Florin Andrei at Mar 9, 2007 at 1:47 am

    Stephen Harris wrote:
    Florin Andrei wrote:
    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.
    But then you've just moved the DST issue into your application and not
    really solved much at all :-)
    No, that's just to display data, at the last stage, when building the
    HTML page, it's a read-only operation and it's just for the internal
    staff. If there are some issues at that level, oh well, I can live with
    that. :-)

    I'm more worried about all kinds of data processing scripts getting
    confused by the clock jumps and mashing data to a pulp. Using UTC should
    take care of that.
    It's really the other clock jump, in autumn, that looks very ugly. The
    one in spring (a few days from now in my TZ) might be much less cumbersome.

    The other way around would be to backtrack through all corner cases and
    add all sorts of conditions to the scripts to avoid the nasty
    consequences of the clock going backwards in autumn. But frankly,
    migrating to UTC seems easier.
  • Steven Vishoot at Mar 9, 2007 at 5:56 am

    --- Florin Andrei wrote:

    Stephen Harris wrote:
    Florin Andrei wrote:
    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.
    But then you've just moved the DST issue into your
    application and not
    really solved much at all :-)
    No, that's just to display data, at the last stage,
    when building the
    HTML page, it's a read-only operation and it's just
    for the internal
    staff. If there are some issues at that level, oh
    well, I can live with
    that. :-)

    I'm more worried about all kinds of data processing
    scripts getting
    confused by the clock jumps and mashing data to a
    pulp. Using UTC should
    take care of that.
    It's really the other clock jump, in autumn, that
    looks very ugly. The
    one in spring (a few days from now in my TZ) might
    be much less cumbersome.

    The other way around would be to backtrack through
    all corner cases and
    add all sorts of conditions to the scripts to avoid
    the nasty
    consequences of the clock going backwards in autumn.
    But frankly,
    migrating to UTC seems easier.

    --
    Florin Andrei

    http://florin.myip.org/
    _______________________________________________
    CentOS mailing list
    CentOS@centos.org
    http://lists.centos.org/mailman/listinfo/centos
    where i use to work they would shutdown all schedules
    at 12:01am and wait until after the time change to
    restart the schedules again. though this was a shop
    that had people there 24/7 so they were able to do this.

    Steven


    "On the side of the software box, in the 'System Requirements' section, it said 'Requires Windows or better'. So I installed Linux."
  • Florin Andrei at Mar 9, 2007 at 7:23 am

    Steven Vishoot wrote:
    where i use to work they would shutdown all schedules
    at 12:01am and wait until after the time change to
    restart the schedules again. though this was a shop
    that had people there 24/7 so they were able to do this.
    So, did they turn off crond temporarily, or what?
  • Steven Vishoot at Mar 9, 2007 at 3:51 pm

    --- Florin Andrei wrote:

    Steven Vishoot wrote:
    where i use to work they would shutdown all schedules
    at 12:01am and wait until after the time change to
    restart the schedules again. though this was a shop
    that had people there 24/7 so they were able to do
    this.

    So, did they turn off crond temporarily, or what?

    --
    Florin Andrei

    http://florin.myip.org/
    _______________________________________________
    CentOS mailing list
    CentOS@centos.org
    http://lists.centos.org/mailman/listinfo/centos
    to be honest i can not remember if they did. what i
    think they had going is nothing normally ran at that
    time. but i am not totally sure.

    Steven


    "On the side of the software box, in the 'System Requirements' section, it said 'Requires Windows or better'. So I installed Linux."

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedMar 8, '07 at 8:04p
activeMar 10, '07 at 1:12p
posts14
users7
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase