[VoiceOps] DST handling

Peter Beckman beckman at angryox.com
Thu Nov 5 16:03:42 EST 2009


On Wed, 4 Nov 2009, Colin wrote:

> GMT for the win.

  Agreed, though we use UTC.  While GMT and UTC are mostly the same, UTC is
  based on atomic time and includes leap seconds that are added occasionally
  to account for the irregularity in the earth and sun's movements.  We
  decided UTC was a more accurate and "official" representation of time.
  GMT is based on the hypothetical average day at Greenwich, which is much
  less scientifically accurate.

  Everything in our system is stored as UTC, and we convert on a per-user
  basis when displaying call logs and the like.  That way we avoid any
  issues with DST.

  I would make all of your CPE devices on UTC as well.  It avoids confusion
  about what time zone any date/time in your system is on the back end.
  Build the conversion into your front-end systems and reporting on a
  per-customer basis.

  You also avoid calls that were really 4 minutes, but get billed as -56
  minutes or 64 minutes for calls during the change from/to DST.

  In discussing time, one of my providers avoids syncing their servers to
  the correct time on an ongoing basis (i.e. with ntpd), with the argument
  that if they sync during calls, billing would be wrong.  Some of there
  servers therefore skew a LOT, and sometimes their call servers can be off
  the real time by _HOURS_ (I suspect this is due to running Asterisk on VMs
  which are notoriously bad at keeping time).  I've griped about it, but
  they say they only sync the time when there are no calls at midnight,
  which never happens.

  Has anyone else been frustrated by the lack of punctuality/analness when
  it comes to making sure clocks are accurate when it comes to call records?

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


More information about the VoiceOps mailing list