|Issue No. #16||24 September 2004||ISSN: 1532-1886|
We encourage you to forward this newsletter to others. Please also CC to firstname.lastname@example.org so that they get a free subscription too.
a Day isn't Always 24 Hours Long
by Carl Wright
In 1998 I was involved in several meetings sponsored by Pulver.com to develop a standard Voice Over IP call detail record. During the meetings one group wanted to record the start and end times for a call and leave the calculation of the duration to the billing systems. I felt that they were trying to avoid work in the real-time call processing application that would reduce the number of calls they could process. I was among an opposing group that wanted the switching equipment to calculate the duration for the CDR. I argued strongly for this approach because most switches do this and most billing systems expect the duration to be in the CDR. I didn't have a logical reason for using the duration. I figured that telephone companies had tried both ideas years ago and settled on delivering durations to the billing applications. I soon learned a better reason for my approach.
Our System Failed
Later that year one of my own systems showed me the reason we should use the duration. We had a real time data system that processed call records from multiple switches and delivered them to a billing system. One of its features was a report that gathered statistical information on the number of calls processed in each hour of each day.
On the face of it, the reporting process was simple. We accumulated information during each hour and stored it for reporting. We tested the system and then put it into production. It worked great until a day in the fall. That day it generated an error when we tried to store the hour's accumulated data. The program discovered that we had already stored that data for that hour. We had a duplicate hour. We had forgotten about Daylight Savings Time.
The Common Assumption
When developers or business planners define how they will process data, they start with certain basic assumptions. Most assume that there are 24 hours in a day. I used to, but I was wrong. In most of the industrialized world (about 70 countries) we use Daylight Savings Time. This means that in the United States that we have a 23 hour day and a 25 hour day each year.
Figure 1. The day on the left is the 23 hour day. The other is a 25 hour day.
So what do you do about Daylight Savings Time?
Avoid it. You can record everything in Greenwich Mean Time (or some other alternative) and never use Daylight Savings Time. This doesn't work if you have to define rates in the local time of the caller. This is probably only going to happen if you don't vary your rates by time of day. An additional problem that comes from using GMT is that you have to decide what to do when you change your rates on a certain date. Again this is a situation where customers expect you to use their time-reference for the end of the day so you have to change the rates at a time other than midnight GMT.
Deal with it. Develop your algorithms to include the time zone (for example, Eastern Standard Time & Eastern Daylight Time) as part of the storage of time and calculate the time between two events based on the time zones of the start and end times. Be ready for the time zones to be different on the start and end times.
Ignore it. I fear this may be more common than anyone realizes. Just process the start and end times as though they are both in the same time zone. Sometime you lose an hour. Sometimes you gain one. Most of the time the damage is limited because the time changes during a time of day when usage is limited.
See http://www.timeanddate.com/time/aboutdst.html for a great chart showing how time transitions into and out of Daylight Savings Time during each year. This web site also shows which countries are using daylight savings time on any day.
See http://webexhibits.org/daylightsaving/ for an explanation of the history of Daylight Savings Time. It also covers how Daylight Savings Time is done in countries other than the United States. The coverage of international alternatives in interesting. Some countries time shift by two hours and other time shift by 30 minutes.
Developing systems to work with real world events compels you to design/implement to handle the messy, complex realities of our world. Daylight Savings Time adds another messy element to the many issues that affect rating and billing. Making systems capable of running anywhere in the world requires you to deal with places that don't do daylight savings time and places that have 2 hour or 30 minute time shifts.
Tell Me What You Want To Hear About
The subjects that I cover in Rating Matters are driven by my personal interests in rating and billing. These are limited by the breadth of my personal experience. Please let me know about items you want to hear about or you'd like explored further. Send me your requests at .
To add a subscription, click here to fill out a form. To delete a subscription, click here to delete. Thanks.
2004 Service Level Corporation
Rating Matters is a trademark of Service Level Corporation