Slashdot Mirror

← Back to Stories (view on slashdot.org)

GoDaddy Bobbles DST Changeover?

Posted by kdawson on from the time-for-a-change dept.

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.

3 of 201 comments (clear)

  1. Timezones by Alioth · · Score: 5, Informative

    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.

    --
    Oolite: Elite-like game. For Mac, Linux and Windows
    1. Re:Timezones by Scott+Wunsch · · Score: 4, Informative

      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.

      --
      \\'
  2. IntellAdmin blew it with their DST fix by Animats · · Score: 5, Informative

    Remember IntellAdmin, 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.