The Old Joel on Software Forum: Part 4 (of 5)

Time Zones

Howdy,

I'm having some problems with an SMS sending engine that is supposed to send an SMS to clients at customised times, in their own time zone. I'll explain how the system works, because I'm having a problem with the time zones part.

At 9:00AM in Australian Central time (GMT +9:30), a script is run that collects data and creates an SMS to be sent.

The SMS is added to a queue (in a database) of SMS that haven't been sent yet. The time it is supposed to send (for example, 4:00 PM, the clients time), and their time zone are recorded as a GMT TIMESTAMP.

Every half hour, another script runs and sends any SMS that need to be sent within a 15 minute period +/- the current time. This ensures all SMS are sent. The current GMT time is calculated, and compared to the time the SMS is supposed to be sent, and if it's within the 15 minute +/- period, the SMS is sent.

My problem is with the calculations, to figure out what time the SMS should be sent. The server is located in the United States, at GMT - 8:30.

So, is this what my calculation for when the SMS is sent should be?

time() + 8*60*60 // To get to GMT time
+ UsersTimeZone*60*60 // Take their Time Zone into account
+ 9.5*60*60 // Because the script ran at australian cent. time
+ TimeOfDayToSend // Because they chose when it sent
- 9*60*60 // Because it's already 9:00AM when it was sent

It's all very confusing

Paul Stovell
Saturday, March 27, 2004

==>It's all very confusing

Only because you're making it so confusing.

Start with creating 2 simple functions:

ConvertToGMT(theLocalTime, theOffset)
ConvertFromGMT(theLocalTime, theOffset)

Before doing any calculations, convert all times to GMT. Then do all calculations in GMT, and then convert the output from GMT to wherever it's appropriate for the output.

You can even add a third handy function by nesting them to convert from one timezone to another:

ConvertTime(theTime, fromOffset, toOffset)
{
return ConvertFromGMT(ConvertToGMT(theTime, fromOffset),toOffset)
}

If you're not used to it, it can be difficult to read, but once you get used to it it will be much easier to do these sorts of things.

See if that's enough to get you going down the right track.

It makes it much simpler when you think about it this way.

Sgt. Sausage
Saturday, March 27, 2004

You are writing the server, or just trying to pump entries to it? Are you sure that you have the format of the time correct? I know that the timestamp component of an SMS header is, err, somewhat unconventional (not as "unconventional" as the two adress components, which have different formats, but odd regardless) so if the server is taking the time in that format then, well, good luck.

And yes, I agree that TZs are a little confusing. If you are using the Windows functions things get even worse because they seem to have a completely opposite view of these offsets than what is implied (that's not very clear, but to be honest I found it so confusing myself when I had to look at it that I'm really not surprised that I can't say it more clearly!). Short version: make sure your + and - signs are the way the functions are expecting them (which may be diferent to what you expect).

Saturday, March 27, 2004

I would say make sure all times in the database are in GMT. Convert the user's requested transmission time to GMT immediately before inserting it into the DB. During the half-hour checks, convert the server's current time to GMT, and then make all comparisons with GMT time.

GetSystemTime() on Windows returns the current time in GMT. So the only hard part you have to worry about is converting the user's request from their own time zone to GMT.

Dan Maas
Saturday, March 27, 2004

We use Date and Time "fixed time around the world" feature to update our clients about server updates. We just include a link in our server update emails to the clients.

For example, here's a link to Saturday March 27, 2004 3:30 PM in San Francisco: http://www.timeanddate.com/worldclock/fixedtime.html?day=27&month=3&year=2004&hour=15&min=30&sec=0&p1=224

It's a nice, simple site. Our clients seem to like it and it reduces confusion about when the servers will be down.

Michael Bean
Saturday, March 27, 2004

Is the U.S. server really at GMT-8:30? That seems odd. I'm not aware of any non-integral-hour time zones in the U.S. or any of its possessions. EST (Eastern Standard Time, e.g. New York) is GMT-5, and PST (Pacific Standard Time, e.g. California) is GMT-8. Just a typo, perhaps?

John C.
Sunday, March 28, 2004

http://www.aglobalworld.com/Zones.html shows that New Delhi and Darwin's time zones are GMT+- H:30 (only two examples).

Jordan
Sunday, March 28, 2004

New Delhi is a US Possession?

Philo

Philo
Sunday, March 28, 2004

Ooops, sorry it was a bit late at night when I wrote that, the time zone for the US server was -8:00 GMT.

Paul
Monday, March 29, 2004

"New Delhi is a US Possession?"

The NDA's on that weren't supposed to be released before Thursday. Now that the cat is out of the bag, you might as well know the background.
Simulation after simulation showed that the only way to stop the current tidlewave of US outsourcing to India was bringing India into the Union.
It seemed strange at first, and to be honest we only put the options into the scenarios 8 years ago after the Europeans announced they where going a similar route with the former eastern block countries. Once the option was in our programs, every last simulation unlocked and trew this up as the ultimate solution. Outcourcing to India disappears overnight, since there is no more India. The whole flow is converted to USA internal market affairs instantly.
And to think people still claim machines can't outsmart humans.

Just me (Sir to you)
Monday, March 29, 2004

don't forget daylight savings!
Sometimes the delta to the server can be + or - 1:00 hour than the usual delta, if one of the zones has changed to daylight savings time and the other hasn't.

Alison, Dublin
Monday, March 29, 2004

---"And to think people still claim machines can't outsmart humans."----

And that Indians can't outsmart the rest of us!

--and themselves all too often :)

Stephen Jones
Monday, March 29, 2004

I was kidding :-)

I know that New Delhi is not a US possession but I wrote this stupid message just to see what would be your reactions :-)

Jordan
Monday, March 29, 2004

From a more OO perspective, you can think of Time as an object that is absolute: its internal state contains something like the number of milliseconds (or whatever) from a certain fixed point of time (epoch: say 1/1/1970 00:00 GMT). It can expose time in any time zone:

zone = getLocalTimeZone();
// zone = TimeZone.getTimeZone("EST");
// zone = TimeZone.getTimeZone("GMT-0500");
// etc.
t = time.getMillisFromEpoch(timezone);

This way, you don't have to worry about "is this integer the time GMT, EST, or AST?" types of questions. Time is time.

joev
Monday, March 29, 2004