GoDaddy Bobbles DST Changeover?

Several readers alerted us to this piece in PC World reporting on concerns that GoDaddy might not be ready for the DST changeover. Some readers, and others, claimed that GoDaddy's servers are not reachable now and are not serving email or web sites; but others see no evidence of this. The article recounts the rather flip response one GoDaddy customer got from their tech support: "As Daylight Savings [sic] does not apply to our servers, since we are on Arizona Time and our time zone does not change, our servers wouldn't update." When IDG News Service contacted GoDaddy they got an altogether more sensible reply.

Timezones

[Alioth]

For international services like domain registrars, switch to UTC already. Running the server on a local timezone will only lead to confusion.

All my internet servers just use UTC. NTP synchronized, naturally.

IntellAdmin blew it with their DST fix

[Animats]

Remember IntellAdmin [intelliadmin.com], offering a free DST patch for Windows 2000? Well, it doesn't work. I installed it on a Win2K system, and the time didn't change to DST. I contacted Intelladmin, and got "workaround instructions" (open clock, change to another time zone, change back, then reset the clock to the correct time.). It only changes to DST the next time you manually set the clock.

So if you deployed this "patch" on your Win2K machines in a corporate environment, the time is going to be wrong when everybody shows up on Monday.

Re:IntellAdmin blew it with their DST fix

[Dr Caleb]

"It only changes to DST the next time you manually set the clock."

"So if you deployed this "patch" on your Win2K machines in a corporate environment, the time is going to be wrong when everybody shows up on Monday."

The Microsoft KB articles said that was exactally what you would have to do with 2000 and NT4. Everyone seemed to think that we were changing the *time* early this morning. Well, we weren't, we changed *timezones*. On 2K and NT4 updating the timezone information only ocurrs when the timzone is changed.

Didn't anybody know what they were doing?

Re:Timezones

[Anonymous Coward]

Your statements are exactly wrong.

UTC is not affected by new laws, timezones or dst. Local time is dependent on local timezone and dst laws.

I think you misunderstand what UTC is, or you are just trolling for replies.

Re:if there is a possibility for a screwup ...

[brokencomputer]

I called GoDaddy and they told me "we're having network issues. We've been having them for a while. I don't know when they'll be fixed but they should be soon." My site is now resolving ( http://wrongplanet.net/ [wrongplanet.net] ) but it wasn't resolving when i called. He didn't say anything about daylight savings time and some of my other domains with godaddy had no problems.

My Linux update

[ortholattice]

Here is how I updated a Linux machine (Debian Woody) for Eastern
time, if anyone is interested.  Some of the information I found on
thar Intraweb was, well, sloppy, and it took some trial-and-error.
The following was exactly what I typed, and it "took" correctly
this morning, with a nice 1-hour gap in the Apache log at 2am.  I
don't know if this is the best way, but it worked.

  su -
    # root password, of course :)
  ls -l /etc/localtime
    # (mine said:  /etc/localtime -> /usr/share/zoneinfo/US/Eastern,
    # in case we have to reverse the procedure below)
  mkdir /root/dst2007
  cd /root/dst2007
  wget ftp://elsie.nci.nih.gov/pub/tzdata2007c.tar.gz
  tar -xzf tzdata2007c.tar.gz
  zic -d zoneinfo northamerica
  cd /usr/share
  mv zoneinfo zoneinfo.old
  mv /root/dst2007/zoneinfo/ .
  ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime
  zdump -v /etc/localtime | grep 2007
     # (should include Mar 11 in listing)

Re:Timezones

[tbo]

GP is correct, actually. Suppose a user schedules an event for 9 am local time. The server re-maps this to UTC, then stores the UTC time. Then, government comes along and changes the mapping between local time and UTC by rescheduling the start of DST. Now, when the server maps back from UTC, the event ends up as 8 am local time. This is probably not what the user wanted.

Uhh.. Whats not "sensible" about that answer?

[Anonymous Coward]

I live in Arizona.

I'm a Unix admin for one of the largest ISPs in the state. We're an AIX house.

I can't speak for our Windows bretheren, but our AIX boxes required absolutely no patching. Our servers calibrate against a UTC source, and the patch IBM offers only affects the optional right-hand portion of $TZ in /etc/environment...A field that doesn't exist if you're MST-7 w/o DST.

GoDaddy's response is entirely sensible.

The only thing not "sensible" here is that you have a bunch of clowns in Congress making decisions with ramifications far beyond their ability to even wrap their brain around.

By the way, our trains run just fine without DST. :)

Re:Timezones

[Scott Wunsch]

Actually, you have that backwards. POSIX timezone definitions (the things you find in /usr/share/zoneinfo on Linux) describe how DST works in all different years. If you convert a UTC timestamp in March 2005 to your local timezone, it won't use DST, but if you do it for a UTC timestamp in March 2007, it'll know that then it needs to use DST. Thus, you're actually better off storing everything in UTC, because then you know what time everything really took place / will take place, in any timezone you care to know it in.

Re:Timezones

[Munchr]

There is a setting that tells windows that the system clock is UTC. It is HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInfo rmation\RealTimeIsUniversal. When set to the value 1, windows will apparently treat the system clock as UTC. However, according to Markus Kuhn [cam.ac.uk] there are several bugs, involving the system debugger and the code that calculates DST changes when the key is active.

OFFICIAL GoDaddy.com response

[Elonline]

This morning, March 11, some of our Go Daddy services came under significant and sustained distributed denial of service attacks resulting in intermittent disruptions of various services, including shared hosting and email.

Our Internet Security and Network teams immediately invoked counter-measures to respond to these large scale, sophisticated attacks.

After 4-5 hours of intermittent disruptions of various services this morning, including shared hosting and email, the attack was contained.

Our Internet Security and Network teams will continue to analyze and assess the nature of today's attacks and their characteristics to identify additional defense mechanisms that can be used in the ongoing efforts of Internet Security.

Go Daddy has made and will be continuing to make significant investments in our information security infrastructure to protect from these shifting types of attacks.

This in no way related to the switch to Daylight Savings Time, as some have speculated. With regard to DST, Go Daddy has been engaged in preparation and patching and worked closely with our vendors for some time leading up to the DST change. leading up to the DST change.

Neil Warner
Chief Information Security Officer
The Go Daddy Group, Inc.

Re:Timezones & embedded firmware

[MaggieL]

Maybe you live somewhere that your clock ended up locking into CHU, the atomic clock in Canada...

I've never seen a clock that synced from CHU (3.33 MHz and 7.335 MHz)...or from WWV/WWVH (2.5, 5, 10, 15 and 20 MHz), for that matter.

The clocks and watches that feature "atomic time" use the signals from WWVB on 60 KHz.

--
73 de Maggie K3XS
Editor, Phil-Mont Mobile Radio Club Blurb - http://www.phil-mont.org/ [phil-mont.org]
Elecraft K2 #1641 -- AOPA 925383 -- ARRL 39280

Re:Timezones

[cookd]

Just to avoid confusion on the terms -

Windows maintains its internal clock as UTC. Things just get too messy otherwise.

Windows does not currently have working support for a CMOS (hardware) clock that is not set to local time. It converts the internal UTC time to local time before updating the hardware clock, and when reading the hardware clock, Windows assumes it is set to local time. (This is rather silly if you ask me. Unfortunately, nobody ever asks me.)

Re:Timezones & embedded firmware

[Technician]

My atomic clocked changed just fine. Also, I was always under the impression that the DST function wasn't built into the clock itself, but into the data stream coming from WWV or WWVH (depending on your location.)

The clock manufactures have the option of either reading the DST bit, or using an internal table. Many manufactures have opted for the internal table, especialy those marketing to non-USA markets such as South America. My SkyScan clock did not update. I even forced a reset to see if it didn't catch the update. It still has no idea it's daylight savings time. I switched DST off so it does not become wrong in April and moved timezones one to the East. My clock uses an internal table and does not use the DST bit. It is not mentioned in any of the clock specifications.