3/2     Lets say you are running a website connected to a database.  The
        website stores all sorts of time sensative info in the database,
        like order timestamps, keeping track of various states of stuff,
        etc.  When we go on or off daylight savings time, doesn't that totally
        mess up things that deal with spans of time? How do you deal with that?
        And how do you display things to the user when they happen right around
        the switch-over?  How about people living in regions like Arizona or
        Hawaii, who don't have daylight savings time?
        \_ Your server needs to have a notion of timezone. Certainly it
           should know its own, and most likely that of its users as well (if
           it doesn't, the users are much more likely to be confused by
           consistently wrong-timezone timestamps than by the 2-hours-a-year
           DST problem). Once it does, you should store dates internally
           either in a timezone-insensitive format (read the time(3) manpage,
           i.e. "man 3 time"), or in a timezone-sensitive format with the
           timezone stored as well (although the former is recommended).
           The standard notion of timezone encodes the DST status as well.
           If you store dates in GMT, GMT is completely DST-free. If you store
           them in, say, Pacific, it will have timezone PST for normal time
           and PDT for daylight saving time. So the date that gets displayed
           as "Sun Apr  3 01:18:19 PST 2005", and is stored internally as
           1112519899, is one hour earlier than the date displayed as
           "Sun Apr  3 03:18:19 PDT 2005" and stored internally as 1112523499.
           This is obvious when you deal with the internal representations:
           1112523499-1112519899=3600. -alexf
          \_ UTC
                \_ I guess my related question was, what if someone changes the
                   the time back 1 hour ... Or on a real server would no one
                   do that ever.
                   \_ Use UTC for everything. Use NTP to keep it synchronized.
                      UTC only changes by one leap second every few years.
            \_ Gah, fine, UTC, not GMT, I stand corrected. Nitpickers. -alexf
               \_ If, for some reason, you want to know a *lot* more about
                  the history of UTC, GMT and precision time keeping in general,
                  you might enjoy reading "Splitting the Second", by Tony Jones.
        \_ In practice, you don't have to worry about this.  Use your database
           server's native DATETIME (mysql) or TIMESTAMP (everyone else) data
           type.  Store the current time using SYSDATE (oracle) or NOW()
           (everyone else).  When you access it formatted, you'll get it
           in the local time format.  So you have to worry about fucking with
           your clock, by not about changing time zones.