Re: DST Changes

From: Kumar, Praveen (cahoot) (Praveen.Kumar_at_CAHOOT.COM)
Date: 02/25/04

  • Next message: Adams Kevin J: "Re: DST Changes" 
    Date:         Wed, 25 Feb 2004 18:58:44 -0000
To: aix-l@Princeton.EDU

    Simon,
            Thanks for the response!!The issue here is that DST is not set to
    on,so currently we are doing a manual time change,so in such scenarios are
    there any special issues to be taken care. or is it just stop all your
    applications and set the time back/forward as applicable.

    TIA
    Praveen.K

    -----Original Message-----
    From: Green, Simon [mailto:Simon.Green@EU.ALTRIA.COM]
    Sent: 25 February 2004 17:19
    To: aix-l@Princeton.EDU
    Subject: Re: DST Changes

    Provided your Timezone is set correctly, (TZ in /etc/environment) there
    should not be any problem and there is no need to take any further action.
    It's worth remembering that ideally you should re-boot your system if you
    have to make a change to TZ, but it's not always strictly necessary: I made
    a lot of changes recently and all I've done is restart the cron daemon and
    ensure that the applications, (mostly SAP and Data Warehouse systems) are
    re-started - not actually a full reboot of the systems.

    Any half-way decent application will use the actual system clock for
    critical things like database log timestamps, so there is no problem there.

    It's possible that you'll see overlapping time-stamps in text logs, but that
    won't do any harm in itself. Technical personnel should be aware of it.

    Scheduling - through crontab or actual scheduling packages - may have some
    issues, with jobs getting missed in the spring, or running twice in the
    autumn. However, that's highly dependent on the particular scheduling
    system. Crontab's very basic, obviously, but a good scheduler should handle
    the situation cleanly.

    Personally, I haven't taken any special actions for DST in several years.
    We did have some problems last autumn because TZ was not identical on all of
    our servers, in particular there were difference between some SAP
    Application servers and their Database servers. This arose because of
    differences in when the time change occurred:-

    Some of the servers had TZ=CET-1CEST,M3.5.0/02,M10.5.0/03, others only had
    CET-1CEST,M3.5.0,M10.5.0. In the second case, the time for the change
    defaults to the US standard, which is 2am local time in both cases. In
    Europe, the standard is for 01:00 GMT, which equates to 02:00 CET in the
    spring, or 03:00 CET in the autumn.

    In fact, this doesn't really matter very much in most cases, provided you
    are consistent.

    The correct TZ for the UK is "GMT0BST,M3.5.0/01,M10.5.0/02". You can either
    edit /etc/environment, or use the chtz command. 

    --
Simon Green
Altria ITSC Europe Ltd
AIX-L Archive at https://new-lists.princeton.edu/listserv/aix-l.html
New to AIX? http://publib-b.boulder.ibm.com/redbooks.nsf/portals/UNIX
N.B. Unsolicited email from vendors will not be appreciated.
Please post all follow-ups to the list.
> -----Original Message-----
> From: Kumar, Praveen (cahoot) [mailto:Praveen.Kumar@CAHOOT.COM]
> Sent: 25 February 2004 16:32
> To: aix-l@Princeton.EDU
> Subject: DST Changes
>
>
> Hi All,
>
>         Can someone let me know what are the issues to be
> taken care during
> DayLight Saving Time changes. My aix boxes have Websphere and
> HTTP Server
> running on them..
.sophos.3.78d.02.24.
*********************
Internet communications are not necessarily secure and may be intercepted or
changed after they are sent.  cahoot does not accept liability for any such
changes.
If you wish to confirm the origin or content of this communication, please
contact the sender using an alternative means of communication.
This communication does not create or modify any contract.
This email may contain confidential information intended solely for use by
the addressee.  If you are not the intended recipient of this communication
you should destroy it without copying, disclosing or otherwise using its
contents.
Please notify the sender immediately of the error.
cahoot is a division of Abbey National plc.
Abbey National plc is registered in England, registered number 2294747.
Registered Office: Abbey National House, 2 Triton Square, Regent's Place,
London, NW1 3AN.
  • Next message: Adams Kevin J: "Re: DST Changes"

    Relevant Pages

    • Re: use .net remoting?
      ... This exchange of information is within a company's intranet. ... firewall to worry about.All the servers are either win2000 or win2003 ... This communication is necessary since the "main part" of the ...
      (microsoft.public.dotnet.framework.aspnet)
    • Losing time
      ... I mean on day 1 if the difference between two servers is 2 ... If you wish to confirm the origin or content of this communication, ... cahoot is a division of Abbey National plc. ... Abbey National plc is registered in England, ...
      (AIX-L)
    • [Full-disclosure] Re: ZoneAlarm phones home
      ... communication to the Zone Labs servers. ... Please note, as with other security software, if you disable this ...
      (Full-Disclosure)
    • Cost of utilising existing SAN storage
      ... we have a StorEdge SE69690 SAN Storage array. ... We are considering upgrading one of our servers ... than the hardware costs? ... This communication and any accompanying ...
      (SunManagers)
    • Re: Vernacular and Linnaean Naming (Was: KT boundary event)
      ... If all you care about is notions of meaning, of language, of ... If you're talking about the communication of scientific information to ... As the scientific community relies on consistency ... Perhaps you'd care to ...
      (talk.origins)