[VoiceOps] DST handling

[Peter Beckman]

On Fri, 6 Nov 2009, David Hiers wrote:

> My system clocks are all within 1 second of time.gov just days after
> the DST change.  We made the jump all at once, got double the number
> of hourly CDR files for an hour, and will get no CDR files for an hour
> in the spring.  Don't think that we did anything special...

  Except what happened to calls active during the change?  Or did you just
  get lucky?

> What do your clocks look like today?

  Average -0.02 seconds off of UTC.

> We show start time and duration for customer-facing reports.

  And it makes it so easy to do such things as:

     MySQL: select convert_tz(starttime, 'UTC', 'America/New_York') from calls
     PHP: date_default_timezone_set('America/New_York');
          echo date('r', $calls[0]['startdate']); // UTC from DB, now displayed as US/EST

  The nice thing about doing it in your code rather than your MySQL is that
  you can easily change the time zone for the entire site on a per-user
  basis just by storing their time zone in a user variable.

  This also means it is really easy for users to change the time/date if
  they are travelling.  We have US customers who go to Europe and simply
  change the Time Zone for their account while in Europe so calls are shown
  in their local time, and since we use POSIX Time Zone names, and we keep
  our servers up to date, we don't have to know that where they are is 30
  minutes off.

  If you are running a phone company, and you aren't storing your call
  records (or event records for that matter) in UTC, in my opinion you're
  doing it wrong.

---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
beckman at angryox.com                                 http://www.angryox.com/
---------------------------------------------------------------------------