It's All About Timing
-
I never thought of this, though to be fair, I don't live in Indiana. But if you do, your Windows systems need a patch for the Daylight Savings Time change. I'd recommend you get this for home and work PCs since you never know what might break or function strangely if you don't.
I look forward to daylight savings time each spring. It makes a huge difference in daylight and the amount of time that we can enjoy the outsides. It's artificial, but hey, I'm human and enjoy the change.
In a computer server world, however, the time drift can affect your network. There are some time sensitive items, especially security tokens with Kerberos, that can be hard to diagnose if you have too much drift between servers.
I've seen issues in the past at a few jobs. Usually more of an annoyance, but it can be a real pain if people start questioning your reports, especially SQL Server ones. Having a server off by a few minutes is usually not a huge problem although its not hard to synch them. Having your SQL Server drift off by a few hours over time, however, means that you might show sales on the wrong day, month, or even year!! Not something that you want to try and explain to the bean counters or salespeople. They will be less than pleased.
Hopefully if you're affected you have already tested this. If not, get it onto a non critical server this week and be sure nothing else breaks. After that, cross your fingers this weekend.
Steve Jones
-
'I look forward to daylight savings time each spring. It makes a huge difference in daylight and the amount of time that we can enjoy the outsides.'
I think you will find that the amunt of daylight you get bears little or no relation to the setting of your clocks and watches! DST is a completely daft idea, and causes much more confusion than simply startin work at a different time would.
-
I hate the so-called daylight-saving time... It does not save anything, just forces you to reset your internal clock twice a year. IMHO it would be only to advantage of everybody to stop moving clocks forward and back.
Our biggest energy distributor admitted, that there is no measurable difference in power consumption in the weeks before and after time change. Children now have to get up at 6:00-6:30 "normal" time to be at school in time (DST started last weekend in our country). If I have lots of work, I can hardly enjoy outsides because I'm working from morning till evening anyway; otherwise, most people in our company can come to work at any time between 7:00 and 9:00 and leave for home accordingly. Those that can not, work in shifts, so DST has little significance for them - at least in this respect.
Of course I'm not denying anyone the right to like DST... but since the author said how much he liked it, I felt compelled to step forward for those whose feelings are opposite
Luckily our entire country is in one timezone and we have no counties with their own local time, so it isn't too bad from the viewpoint of DBA. So far, I never needed to solve a problem caused by DST (and hopefully it will remain so...).
Time as such does not exist. Time is something people invented, so that they would know from when, till when, and how much it will cost. (Jan Werich)
-
Something that the MS article forgot to mention but that I have encountered on every machine I've switched over so far (3 home machines and 2 work machines):
If your computer was in the "Indiana" time zone, when you switch it to either Eastern or Central, the "Observe daylight savings time" box is not checked by default. So if you're not paying attention, you can switch your time zone and still not fix the problem.
-
I've had one server get out of sync and be showing time about 15 hours ahead - looked like you'd done a day's work before you started!
The problem was with the backups. Not only did they occur at the busy times instead of the wee small hours but the subsequent file transfer was rejected by the receiving server because of the time inconsistency. Had we lost that server we would have been in big trouble.
As for clock fiddling, here in the UK in my youth we tried a three year experiment of leaving the clocks on British Summertime (GMT + 1) for the whole period. I and most English folk thought it was much better as it was lighter in the evenings as well as the mornings but the Scottish hated it, being further north and having shorter days so we had to go back to the old GMT in winter, BST in summer. This year both my car clocks were left on BST for the winter and I'm just getting used to them being right again!
I still think it's one of life's wonders that the computers now manage to sort themselves out each time - I can remember when they didn't and half the day was spent adjusting clocks and sorting out jobs and schedules and so on.
-
Another tweak/patch to the map. While Arizona is technically on Mountain Time, most of the state does not switch to daylight savings time (I think it's just some areas of the Navajo reservation that does it). Here in Arizona, I wish we could have Daylight Wasting Time in the summer so that that large HOT orange thing in the sky would go away SOONER each day and we can come out and play.
Not too much concern for our servers, as long as they recognize that we are in a zone that does not switch.
-
I didn't see a great map when searching on Google.
Plus I liked this one
-
I disagree that it causes more trouble than changing work time.
It changes the schedule of all operations and systems together. Your train schedule shifts the same amount as your work schedule, there is not confusion as to whether business X has changed their hours or not.
Additionally organizations do not need to touch their schedules, which would be an expensive operation.
...
-- FORTRAN manual for Xerox Computers --
-
Being a Hoosier like Jeff (CST near Chicago) I've had to deal with this 'thing' for some time now. The real pain is not Windows or SQL Server nor servers getting out of sync - server build 'standards' and NTP servers handle this aspect of the situation quite nicely. It's more of an application born pain. At our site we use at least 100 different vendor solutions. These systems vary in complexity from single server to 2 and 3 tiered and then farm based and multi-platform. Some vendor software recognizes the change from Windows, some from SQL Server, some from their own configurations (actually a lot of them ... ughhh). Oh, and I almost forgot, client specific software on PCs as well (about 1200 of them) So every time change weekend our team of system engineers is going over vendor specs and what not looking forward to our twice a year all-nighter ... I say make us hourly twice a year !!!
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
-
My sympathies...
Hourly twice a year should at least get you that vacation home "now" than "then" so your best bet is to make this nightmare work for you and start making your voice heard....
**ASCII stupid question, get a stupid ANSI !!!** -
This reminds me of an anecdote that happened to me one October. I was developing e-commerce sites at the time, and a client called an said something weird was going on and that the order numbers were out of sequence.
Essentially, our order number was an identity column and somehow orders placed at, say, 1:05 am had a lower order number than one placed at 1:10 - until we realized that the server had self-adjusted to go back (fall back) to standard time.
Who ever thought that orders would be placed at 1am?
I am Doing it with .Net, are you?
-
Maybe I'm blind: there is no patch to get. The linked to page just explains you have to change your timezone setting. (which is worth making sure people are aware of but you made it sound like you needed to download and install something which would probably confuse people too...)
-
I can't stand DST -- Just a host of problems for people and computers.
The sync problems have gone away a lot since the days of NT4. We had to rebuild a server that had just gone bad. We couldn't get it to delete out of the domain so we could put it back in. Evvery time we deleted it it would show back up in 10 minutes or so. We went nuts for about 2 hrs trying to figure it out.
Turns out a BDC at a remote site was 45 minutes ahead of the PDC. We then ran a net time to get back in sync and that solved it.
----------------
Jim P.A little bit of this and a little byte of that can cause bloatware.
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply