NZ Daylight Savings change impact

Discussion in 'NZ Computing' started by Jim.Seedlenissip@gmail.com, Aug 15, 2007.

  1. Guest

    NZ Daylight Savings change impact (start and end dates are different
    this year)
    Trying to identify if this is a big deal or not.... MS have several
    patches out there for updating OS's Exch, SQL etc (some are still
    being developed). Before I bother writing a script to run a registry
    change on hundreds of workstations, servers and laptops, what is the
    true exposure to issues if we do not patch everything?

    For example if we patched all servers but no end user XP platforms,
    will the workstations happily adjust via the time sych we have in the
    logon script? Or will we still have issues?

    Getting pressure from Execs to cover this one off soon, any comments?

    Cheers
    , Aug 15, 2007
    #1
    1. Advertising

  2. Kent Smith Guest

    wrote:
    > NZ Daylight Savings change impact (start and end dates are different
    > this year)
    > Trying to identify if this is a big deal or not.... MS have several
    > patches out there for updating OS's Exch, SQL etc (some are still
    > being developed). Before I bother writing a script to run a registry
    > change on hundreds of workstations, servers and laptops, what is the
    > true exposure to issues if we do not patch everything?
    >
    > For example if we patched all servers but no end user XP platforms,
    > will the workstations happily adjust via the time sych we have in the
    > logon script? Or will we still have issues?
    >
    > Getting pressure from Execs to cover this one off soon, any comments?
    >
    > Cheers


    By default the time sync service syncs from a DC unless you've told it to go
    to a internal or external NNTP server. So in theory you could just update
    your DC's. Test it though. :)


    -KENT
    Kent Smith, Aug 15, 2007
    #2
    1. Advertising

  3. Guest

    Agreed, but if having daylight savings enabled on a desktop adjusts
    the time according to the rules around daylight savings, then surely
    it will need to be changed.
    Has anyone tested this with an XP client and a Windows DC?
    , Aug 15, 2007
    #3
  4. Alan Guest

    Hi Jim,

    I think this just happened recently in the US (this year I believe).

    You might try posting to any US or global group (but not an NZ one) to
    find out what happened there?

    HTH,
    --

    Alan.

    The views expressed are my own, and not those of my employer or anyone
    else associated with me.

    My current valid email address is:



    This is valid as is. It is not munged, or altered at all.

    It will be valid for AT LEAST one month from the date of this post.

    If you are trying to contact me after that time,
    it MAY still be valid, but may also have been
    deactivated due to spam. If so, and you want
    to contact me by email, try searching for a
    more recent post by me to find my current
    email address.

    The following is a (probably!) totally unique
    and meaningless string of characters that you
    can use to find posts by me in a search engine:

    ewygchvboocno43vb674b6nq46tvb




    <> wrote in message
    news:...
    > Agreed, but if having daylight savings enabled on a desktop adjusts
    > the time according to the rules around daylight savings, then surely
    > it will need to be changed.
    > Has anyone tested this with an XP client and a Windows DC?
    >
    Alan, Aug 15, 2007
    #4
  5. Steve Guest

    On Wed, 15 Aug 2007 15:31:28 +1200, Kent Smith wrote:

    > By default the time sync service syncs from a DC unless you've told it to go
    > to a internal or external NNTP server. So in theory you could just update
    > your DC's. Test it though. :)
    >
    >
    > -KENT

    <pedant>
    Don't think the newsgroup servers'll care much about your time :)
    </pedant>

    I know it's a trivial change on *nix, and would hope that it's the same
    for all operating systems - after all it changes twice a year anyway!
    Steve, Aug 15, 2007
    #5
  6. In message <f9u47q$6t8$>, Steve wrote:

    > I know it's a trivial change on *nix, and would hope that it's the same
    > for all operating systems - after all it changes twice a year anyway!


    *nix systems don't need to change anything twice a year, because they
    maintain system time in UTC. Windows isn't quite so smart.

    Also the US change earlier this year necessitated patches to a number of
    Windows applications as well. The same thing will apply here.

    Why are these additional patches required? Because those apps insist on
    using their own date/time calculation functions, instead of relying on the
    system ones. Aren't the system ones good enough? Maybe not on Windows...
    Lawrence D'Oliveiro, Aug 15, 2007
    #6
  7. lolinternet Guest

    Lawrence D'Oliveiro wrote:
    > In message <f9u47q$6t8$>, Steve wrote:
    >
    >> I know it's a trivial change on *nix, and would hope that it's the same
    >> for all operating systems - after all it changes twice a year anyway!

    >
    > *nix systems don't need to change anything twice a year, because they
    > maintain system time in UTC. Windows isn't quite so smart.


    God you can be a plonk at times.

    I run a server farm with 60+ Linux servers, I use a Linux workstation. I
    think Linux is great, but your crusading is ridiculous to the point of
    being embarassing to *nix users.

    Your mutterings about UTC is irrelevant here.

    UTC as the system time or not, doesn't have any impact on the fact that
    locale wise, DST is over a different period.

    So for user facing interfaces (Linux, Windows, Mac, etc) the displayed
    time will be _wrong_ - that fact is platform agnostic.

    If you run your desktop at UTC and manually localise yourself then great
    for you, but the _real_ issue is far from where you're at.
    lolinternet, Aug 15, 2007
    #7
  8. lolinternet wrote:
    > Lawrence D'Oliveiro wrote:
    >> In message <f9u47q$6t8$>, Steve wrote:
    >>> I know it's a trivial change on *nix, and would hope that it's the same
    >>> for all operating systems - after all it changes twice a year anyway!

    >>
    >> *nix systems don't need to change anything twice a year, because they
    >> maintain system time in UTC. Windows isn't quite so smart.

    >
    > God you can be a plonk at times.
    >
    > I run a server farm with 60+ Linux servers, I use a Linux workstation. I
    > think Linux is great, but your crusading is ridiculous to the point of
    > being embarassing to *nix users.
    >
    > Your mutterings about UTC is irrelevant here.
    >
    > UTC as the system time or not, doesn't have any impact on the fact that
    > locale wise, DST is over a different period.
    >
    > So for user facing interfaces (Linux, Windows, Mac, etc) the displayed
    > time will be _wrong_ - that fact is platform agnostic.
    >
    > If you run your desktop at UTC and manually localise yourself then great
    > for you, but the _real_ issue is far from where you're at.


    Seconded.
    Mark Robinson, Aug 15, 2007
    #8
  9. In message <46c2b2e1$>, lolinternet wrote:

    > God you can be a plonk at times.


    I tend to ignore things like that because it's clear you haven't thought
    about the issues before posting. Make sure brain is in gear before engaging
    mouth, and all that.

    Besides, I'm not God. :)

    > UTC as the system time or not, doesn't have any impact on the fact that
    > locale wise, DST is over a different period.


    Yes it does have impact.

    > So for user facing interfaces (Linux, Windows, Mac, etc) the displayed
    > time will be _wrong_ - that fact is platform agnostic.


    The effect can be quite different depending on whether the system keeps time
    in UTC or not. Just a few months back the US went through what will be
    happening to us soon, when their new daylight-saving rules came into
    effect. Some Windows systems were set an hour ahead at the new transition
    time, only to jump another hour ahead at the old transition time--funny
    things like that. You get all these weird effects because local time is
    inherently ambiguous, and when it needs to be adjusted every now and then,
    but your only reference is the local time itself, it's easy to lose track
    of whether you've done the adjustment or not, and either forget to do it or
    do it twice.

    UTC is not ambiguous. Because in Linux systems the offset to local time is
    recomputed from UTC every time you ask for the time, there's no need to
    remember whether you've changed to a different offset or not: you simply
    determine what offset needs to be applied at the current UTC time.
    Lawrence D'Oliveiro, Aug 15, 2007
    #9
  10. lolinternet Guest

    Lawrence D'Oliveiro wrote:
    > UTC is not ambiguous. Because in Linux systems the offset to local time is
    > recomputed from UTC every time you ask for the time, there's no need to
    > remember whether you've changed to a different offset or not: you simply
    > determine what offset needs to be applied at the current UTC time.


    And on Sept 30th, after the rest of the country changes their clocks
    before popping their slippers off and clambering into bed - every Linux
    distribution (unless the maintainers have released an update, or users
    have manually changed their timezone data) will carry on thinking the
    offset is GMT+12 and display the WRONG LOCAL TIME for another week until
    their old definition of the NZDT period kicks in. Just like Windows, and
    Mac OS will.

    Thusly next year, they'll all revert from GMT+13 (or NZDT) back to
    GMT+12 two weeks early.

    This is the point you are missing, and what the OP is trying to counter,
    and as previously stated has 5/8 sod all to do with UTC being the base
    system time or not.

    I find this particularly ironic given your own thread on this not more
    than a few days ago.
    lolinternet, Aug 15, 2007
    #10
  11. Shane Guest

    lolinternet wrote:

    > Lawrence D'Oliveiro wrote:
    >> UTC is not ambiguous. Because in Linux systems the offset to local time
    >> is recomputed from UTC every time you ask for the time, there's no need
    >> to remember whether you've changed to a different offset or not: you
    >> simply determine what offset needs to be applied at the current UTC time.

    >
    > And on Sept 30th, after the rest of the country changes their clocks
    > before popping their slippers off and clambering into bed - every Linux
    > distribution (unless the maintainers have released an update, or users
    > have manually changed their timezone data) will carry on thinking the
    > offset is GMT+12 and display the WRONG LOCAL TIME for another week until
    > their old definition of the NZDT period kicks in. Just like Windows, and
    > Mac OS will.
    >
    > Thusly next year, they'll all revert from GMT+13 (or NZDT) back to
    > GMT+12 two weeks early.
    >
    > This is the point you are missing, and what the OP is trying to counter,
    > and as previously stated has 5/8 sod all to do with UTC being the base
    > system time or not.
    >
    > I find this particularly ironic given your own thread on this not more
    > than a few days ago.


    Is there no end to the deceit these nyms are prepared to sow in nz.comp
    http://groups.google.co.nz/group/nz...t group:nz.comp&rnum=2&hl=en#daf2a4974c18efc5
    From the thread:

    Redhat have released patches for enterpirse.

    Debian has a release in volatile at the moment.

    Ubuntu have releases pending.


    Dapper already has it correct.
    shane@laptop:~$ date -d "+49 days"
    Fri Sep 28 20:31:50 NZST 2007
    shane@laptop:~$ date -d "+51 days"
    Sun Sep 30 21:31:58 NZDT 2007

    I've just done dist-upgrade today on Ubuntu, so now 7.10 gutsy tribe
    alpha 3 and daylight saving is correct.

    as does Fedora release 7 (Moonshine)
    --
    Q: What is clear and used by trendy sophisticated engineers to solve other
    differential equations?
    A: The Perrier transform.
    Shane, Aug 15, 2007
    #11
  12. Kent Smith Guest

    Steve wrote:
    > On Wed, 15 Aug 2007 15:31:28 +1200, Kent Smith wrote:
    >
    >> By default the time sync service syncs from a DC unless you've told
    >> it to go to a internal or external NNTP server. So in theory you
    >> could just update your DC's. Test it though. :)
    >>
    >>
    >> -KENT

    > <pedant>
    > Don't think the newsgroup servers'll care much about your time :)
    > </pedant>
    >
    > I know it's a trivial change on *nix, and would hope that it's the
    > same for all operating systems - after all it changes twice a year
    > anyway!


    ooo - NTP :)


    -KENT
    Kent Smith, Aug 16, 2007
    #12
  13. Dave Doe Guest

    In article <>,
    says...
    > NZ Daylight Savings change impact (start and end dates are different
    > this year)
    > Trying to identify if this is a big deal or not.... MS have several
    > patches out there for updating OS's Exch, SQL etc (some are still
    > being developed). Before I bother writing a script to run a registry
    > change on hundreds of workstations, servers and laptops, what is the
    > true exposure to issues if we do not patch everything?
    >
    > For example if we patched all servers but no end user XP platforms,
    > will the workstations happily adjust via the time sych we have in the
    > logon script? Or will we still have issues?
    >
    > Getting pressure from Execs to cover this one off soon, any comments?


    There is some update info here...

    http://www.microsoft.com/nz/msdn/timezone/default.mspx

    --
    Duncan
    Dave Doe, Aug 30, 2007
    #13
  14. Geopelia Guest

    Do we really need all these patches and stuff? I can change the clock myself
    on this computer. And if it doesn't work, won't it change itself on the old
    date?

    I don't think anyone I know will quibble about being an hour out for a week
    or so.

    Geopelia
    Geopelia, Aug 30, 2007
    #14
  15. Kent Smith Guest

    Geopelia wrote:
    > Do we really need all these patches and stuff? I can change the clock
    > myself on this computer. And if it doesn't work, won't it change
    > itself on the old date?
    >
    > I don't think anyone I know will quibble about being an hour out for
    > a week or so.
    >
    > Geopelia


    The time is normally worked out as an offset from UTC/GMT. e.g GMT+12 for
    NZST and GMT+13 for NZDT. The offset is based on the timezone and each
    timezone has daylight savings rules. If the daylight savings rules are
    incorrect, even if you change the time locally to make it correct, when it
    next syncs with UTC, it'll change back again.

    But yes, it'll become correct on the old dates.

    You could set your timezone to Kiribati or something (GMT+13) perhaps.


    -KENT
    Kent Smith, Aug 31, 2007
    #15
  16. Mutlley Guest

    "Kent Smith" <> wrote:

    >Geopelia wrote:
    >> Do we really need all these patches and stuff? I can change the clock
    >> myself on this computer. And if it doesn't work, won't it change
    >> itself on the old date?
    >>
    >> I don't think anyone I know will quibble about being an hour out for
    >> a week or so.
    >>
    >> Geopelia

    >
    >The time is normally worked out as an offset from UTC/GMT. e.g GMT+12 for
    >NZST and GMT+13 for NZDT. The offset is based on the timezone and each
    >timezone has daylight savings rules. If the daylight savings rules are
    >incorrect, even if you change the time locally to make it correct, when it
    >next syncs with UTC, it'll change back again.
    >
    >But yes, it'll become correct on the old dates.
    >
    >You could set your timezone to Kiribati or something (GMT+13) perhaps.
    >
    >
    >-KENT
    >


    I noticed on our Win XP 32 bits PCs at home and at work that the
    daylight savings patch arrived today.. Nothing on the 64 Bit PCs or
    the win2K PCs
    Mutlley, Aug 31, 2007
    #16
  17. Rhino Guest

    On Fri, 31 Aug 2007 14:02:20 +1200, Mutlley <>
    wrote:

    >I noticed on our Win XP 32 bits PCs at home and at work that the
    >daylight savings patch arrived today.. Nothing on the 64 Bit PCs or
    >the win2K PCs


    According to the MS nz site, no patches are planned for win2k. XP SP2
    and 2003server have had patches done on 28 August.

    To update W2k, download tzedit (Timezone Editor) and update the DST
    rules for NZ that way.
    Cheers, Rhino
    Rhino, Aug 31, 2007
    #17
  18. Geopelia Guest

    "Kent Smith" <> wrote in message
    news:fb7lrl$qpm$...
    > Geopelia wrote:
    >> Do we really need all these patches and stuff? I can change the clock
    >> myself on this computer. And if it doesn't work, won't it change
    >> itself on the old date?
    >>
    >> I don't think anyone I know will quibble about being an hour out for
    >> a week or so.
    >>
    >> Geopelia

    >
    > The time is normally worked out as an offset from UTC/GMT. e.g GMT+12 for
    > NZST and GMT+13 for NZDT. The offset is based on the timezone and each
    > timezone has daylight savings rules. If the daylight savings rules are
    > incorrect, even if you change the time locally to make it correct, when it
    > next syncs with UTC, it'll change back again.
    >
    > But yes, it'll become correct on the old dates.
    >
    > You could set your timezone to Kiribati or something (GMT+13) perhaps.
    >
    >
    > -KENT

    Thank you, but that's a bit complicated for me. I'll just stay an hour slow
    for the extra week, as I expect a lot of people will do too. Apart from
    putting the wrong time on emails, what harm could it do?

    Won't the government do something? There must be a lot of government
    computers.

    Geopelia
    Geopelia, Aug 31, 2007
    #18
  19. Kent Smith Guest

    Geopelia wrote:
    > "Kent Smith" <> wrote in message
    > news:fb7lrl$qpm$...
    >> Geopelia wrote:
    >>> Do we really need all these patches and stuff? I can change the
    >>> clock myself on this computer. And if it doesn't work, won't it
    >>> change itself on the old date?
    >>>
    >>> I don't think anyone I know will quibble about being an hour out for
    >>> a week or so.
    >>>
    >>> Geopelia

    >>
    >> The time is normally worked out as an offset from UTC/GMT. e.g
    >> GMT+12 for NZST and GMT+13 for NZDT. The offset is based on the
    >> timezone and each timezone has daylight savings rules. If the
    >> daylight savings rules are incorrect, even if you change the time
    >> locally to make it correct, when it next syncs with UTC, it'll
    >> change back again. But yes, it'll become correct on the old dates.
    >>
    >> You could set your timezone to Kiribati or something (GMT+13)
    >> perhaps. -KENT

    > Thank you, but that's a bit complicated for me. I'll just stay an
    > hour slow for the extra week, as I expect a lot of people will do
    > too. Apart from putting the wrong time on emails, what harm could it
    > do?
    > Won't the government do something? There must be a lot of government
    > computers.
    >

    Biggest problem for home users will probably be if you rely on meeting
    scheduling software for appointments / syncing your phones, etc. Yes,
    little harm, you PC wont crash. :)


    -KENT
    Kent Smith, Sep 2, 2007
    #19
  20. Geopelia Guest

    "Kent Smith" <> wrote in message
    news:fbf8gs$27qn$...
    > Geopelia wrote:
    >> "Kent Smith" <> wrote in message
    >> news:fb7lrl$qpm$...
    >>> Geopelia wrote:
    >>>> Do we really need all these patches and stuff? I can change the
    >>>> clock myself on this computer. And if it doesn't work, won't it
    >>>> change itself on the old date?
    >>>>
    >>>> I don't think anyone I know will quibble about being an hour out for
    >>>> a week or so.
    >>>>
    >>>> Geopelia
    >>>
    >>> The time is normally worked out as an offset from UTC/GMT. e.g
    >>> GMT+12 for NZST and GMT+13 for NZDT. The offset is based on the
    >>> timezone and each timezone has daylight savings rules. If the
    >>> daylight savings rules are incorrect, even if you change the time
    >>> locally to make it correct, when it next syncs with UTC, it'll
    >>> change back again. But yes, it'll become correct on the old dates.
    >>>
    >>> You could set your timezone to Kiribati or something (GMT+13)
    >>> perhaps. -KENT

    >> Thank you, but that's a bit complicated for me. I'll just stay an
    >> hour slow for the extra week, as I expect a lot of people will do
    >> too. Apart from putting the wrong time on emails, what harm could it
    >> do?
    >> Won't the government do something? There must be a lot of government
    >> computers.
    >>

    > Biggest problem for home users will probably be if you rely on meeting
    > scheduling software for appointments / syncing your phones, etc. Yes,
    > little harm, you PC wont crash. :)
    >
    >
    > -KENT

    Thanks, appointments won't worry us, and the car's clock is an hour wrong
    for half the year anyway!

    Geopelia
    Geopelia, Sep 3, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andrew Barnes

    Daylight Savings time configuration

    Andrew Barnes, Mar 23, 2006, in forum: Cisco
    Replies:
    2
    Views:
    1,993
    thrill5
    Mar 24, 2006
  2. Jim Kroger
    Replies:
    2
    Views:
    1,089
    Brian H¹©
    Oct 14, 2003
  3. XtremeHOHA

    Daylight savings time......

    XtremeHOHA, Jan 14, 2005, in forum: Computer Support
    Replies:
    5
    Views:
    652
    Tim K.
    Jan 15, 2005
  4. Newsguy

    Daylight Savings Time Impact

    Newsguy, Jan 17, 2007, in forum: Cisco
    Replies:
    6
    Views:
    488
    Loren Amelang
    Jan 25, 2007
  5. Phil

    Daylight Savings Time Change

    Phil, Feb 18, 2007, in forum: Computer Support
    Replies:
    4
    Views:
    447
Loading...

Share This Page