DST hype
With last minute -pun intended- patches for the DST change being released in the last few days, it's now too late to panic and go about breaking more than what you'll fix.
Let's look ahead at what's likely to be going to happen if you are in or are dealing with others in an affected area:
UPDATED
I've posted a new poll where you can show us how it went for you. Compare it to those of you using their crystal ball skillz. Enjoy!
UPDATE
Jon wrote in with a story of his supplier of punch-clocks that had needed firmware upgrades for the clocks due to the DST change and the pain he felt due to it: Not only was it hard to update the clocks, but worse the clocks started to skip an hour every day since they got update. Clearly his vendor didn't get the reasons for proper testing, or more likely ended up in that spot what I was trying to warn about in the first paragraph: "Now [it's] too late to panic and go about breaking more than what you'll fix". I feel Jon's pain and wish him a speedy recovery of his clocks and the data they collect.
--
Swa Frantzen -- NET2S
Let's look ahead at what's likely to be going to happen if you are in or are dealing with others in an affected area:
- Machines that got patched, including patches for applications keeping their own independent timezone information will likely work without a hick-up.
- Home machines missing an update, or not being supported likely will end up on the wrong time, just as the rest of the house, car and phone. Users know how to update the time (well those that aren't owners of VCRs with a perpetual blinking 00:00 on it anyway). Even so, the impact of this will be mostly negligible.
- Businesses might have meetings, conf. calls etc where participants end up turning up on the wrong time. Simple reminders and rescheduling can fix this, nothing earth shattering will happen. And if you're working in large international businesses this mess happens more often at every DST change where the different continents don't sync the changes, where the southern hemisphere changes in the other direction etc.
- Time sensitive applications in businesses that are still using local time might go wrong. The typical applications there would be logs and access control
- Logs: If you're used to dealing with days that don't have the 2 to 3 hour hour, or -worse- days where 2:30 happens twice, you're well equipped to deal with a log that 's one hour off. Just record when it got straightened out and you'll be fine. If you do need to make changes, out best suggestion is to get rid of local time. UTC rules, it has much less changes (a leap second is about the worst that happens and that can be automated) and it is independent of location, politicians feeling the need to mess with time, and DST changes.
- Access control: Time based access control can be a bit more tricky. But you know that if after all the media attention you still don't have a plan "B", you deserve the wrath of people being mad at you for having been waiting for an hour locked out of the building. Even then it's not going not to be all that huge of an issue.
- Logs: If you're used to dealing with days that don't have the 2 to 3 hour hour, or -worse- days where 2:30 happens twice, you're well equipped to deal with a log that 's one hour off. Just record when it got straightened out and you'll be fine. If you do need to make changes, out best suggestion is to get rid of local time. UTC rules, it has much less changes (a leap second is about the worst that happens and that can be automated) and it is independent of location, politicians feeling the need to mess with time, and DST changes.
- Time critical systems. Well are you sure they are time critical if you're running them using local time? UTC rules here without a doubt!
GEEKS USE UTC
UPDATED
I've posted a new poll where you can show us how it went for you. Compare it to those of you using their crystal ball skillz. Enjoy!
UPDATE
Jon wrote in with a story of his supplier of punch-clocks that had needed firmware upgrades for the clocks due to the DST change and the pain he felt due to it: Not only was it hard to update the clocks, but worse the clocks started to skip an hour every day since they got update. Clearly his vendor didn't get the reasons for proper testing, or more likely ended up in that spot what I was trying to warn about in the first paragraph: "Now [it's] too late to panic and go about breaking more than what you'll fix". I feel Jon's pain and wish him a speedy recovery of his clocks and the data they collect.
--
Swa Frantzen -- NET2S
Keywords:
0 comment(s)
×
Diary Archives
Comments