Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > NZ Computing > NZ Daylight Savings change impact

Reply
Thread Tools

NZ Daylight Savings change impact

 
 
Jim.Seedlenissip@gmail.com
Guest
Posts: n/a
 
      08-15-2007
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

 
Reply With Quote
 
 
 
 
Kent Smith
Guest
Posts: n/a
 
      08-15-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) 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


 
Reply With Quote
 
 
 
 
Jim.Seedlenissip@gmail.com
Guest
Posts: n/a
 
      08-15-2007
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?

 
Reply With Quote
 
Alan
Guest
Posts: n/a
 
      08-15-2007
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:

(E-Mail Removed)

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




<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> 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?
>



 
Reply With Quote
 
Steve
Guest
Posts: n/a
 
      08-15-2007
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!
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      08-15-2007
In message <f9u47q$6t8$(E-Mail Removed)>, 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...
 
Reply With Quote
 
lolinternet
Guest
Posts: n/a
 
      08-15-2007
Lawrence D'Oliveiro wrote:
> In message <f9u47q$6t8$(E-Mail Removed)>, 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.


 
Reply With Quote
 
Mark Robinson
Guest
Posts: n/a
 
      08-15-2007
lolinternet wrote:
> Lawrence D'Oliveiro wrote:
>> In message <f9u47q$6t8$(E-Mail Removed)>, 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.
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      08-15-2007
In message <46c2b2e1$(E-Mail Removed)>, 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.
 
Reply With Quote
 
lolinternet
Guest
Posts: n/a
 
      08-15-2007
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.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
getTime, setTime, recent change in daylight savings Zamdrist Javascript 13 04-09-2009 12:18 PM
Revised daylight savings time impact on code Taps ASP .Net 1 03-09-2007 09:06 PM
Daylight Savings Time Change Phil Computer Support 4 02-21-2007 12:46 AM
Daylight Savings Time Impact Newsguy Cisco 6 01-25-2007 08:02 PM
Daylight Savings time configuration Andrew Barnes Cisco 2 03-24-2006 06:45 PM



Advertisments