Hi Dave, I thought that NTP operated UTC so it wouldn't have any effect on the new time zone. (Just looked it up, apparently I thought correctly) You have to add and subtract from the NTP server result to give you local time.
While I doubt jets will be falling from the sky I think, like you said, that there will be a lot of people operating on a middle time zone accidentally. My plan of attack was to wait and see what needs to be fixed on the second Sunday in March (when things that should be EDT are still EST) and the last Sunday in October (when things should be EDT for another week and have already moved to EST). I think it's a reactive approach, but as long as everything is being stored to my databases correctly it won't matter to me to much, but I'm not doing anything highly sensitive to time. It's going to screw a little with that age-old saying "Spring Forward, Fall Back" though. - Ian On 2/13/07, Dave Donovan <[EMAIL PROTECTED]> wrote:
This Daylight Saving Time change coming up in a month isn't anything on the scale of Y2K but it makes me think the many places where little calculations are made with timestamps. Our Blackberries are going to be a pain. I'm just curious to see what people are thinking about this. It seems like there hasn't been much buzz and many people I've asked haven't given it much thought. I think it's almost like there will be 3 timezones. EST, EDT and Energy Saving EDT. Has anyone run into issues with Asterisk? Obviously, any custom scripts that depend on remote servers are a concern but, other than VM timestamps, and maybe some least cost routing, are there obvious applications/features that you can think need careful consideration? Do you trust your upstream NTP server? Imagine if you patched your system and they didn't patch theirs. How often do your phones poll for NTP sync? Is it often enough that it'll get synced up before your users come in or do you have to check to make sure your firmware is going to handle the change itself. Tell us what you think. Dave
