The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Advice on timezones Unix w/ Python & Perl

We need to display time for multiple time zones from a single server.

Multiple countries with different Daylight Savings Time options.

So, question is, I've got a time instant, say in UTC, and need to display it for various time zones.

Any advice on going about this?
dot for this one
Friday, September 29, 2006
Mike S Send private email
Friday, September 29, 2006
You've already figured out that as far as your server is concerned, all times are UTC. You can then use a simple library provided date formatting function to translate that UTC time into something meaningful to the user. (Perl has several functions and modules available, and I'd suspect Python has almost as many options.)

The real trick is figuring out what time zone the user wants to see time expressed in. It gets harder if you're dealing with remote time rather than local time.

For example, let's say I'm in New York and flying to San Francisco. I want to see arrival time in the Pacific time zone, and my spouse (who is remaining behind) would want to see arrival time in the Eastern time zone. You'll have to display both or ask us which one we want.

And let's not discuss Illinois.

How you should handle this really depends on what kind of application you're writing, and I strongly encourage you, from personal experience, to try to avoid the whole issue entirely.

For example, if you're synchronizing files, it's more reliable for the client to convert its local time into UTC and report back to the server that way, than it is for the server to figure out the client's local time.
Friday, September 29, 2006
Here's the deal:

We have a file with times in UTC, those need to be converted to local time for the location of our server.

We know our timezone so it shouldn't be complicated.

We'd also like to show conversions:


12:30 PM 29 SEPT 2006 PDT
19:30 PM 29 SEPT 2006 UTC
01:00 PM 30 SEPT 2006 -- I think that would be correct for India
... and so forth ...

It doesn't seem worth the trouble to try to localize. These are internal apps used by engineers so they probably already know how to convert to time on West Coast USA.

So we have two tasks:

1: get the time offset from UTC to local time for the files
2: (less important) convert local time to other time zones as a convenience feature.
dot for this one
Friday, September 29, 2006
By localize, I meant determine the time to use when displaying a web page or generating a report.

We just want the conversion as a convenience for our users, who could select their time or look at a page that gives the current time for the zones where we have people located.
dot for this one
Friday, September 29, 2006
"...These are internal apps used by engineers..."

It's probably worth pointing out that these engineers won't really care what timestamp is on the files. Convenient, yes, but they're more concerned with time as a relative concept.

Err...  as an example, you've downloaded your favorite Monty Python skitch from iTunes. A few days later, you discover there's another version of it so you download that too. In this case, you're more concerned with which file is newer (which is a time zone independent concept) than the actual time the file was downloaded.

I could be wrong - and I'm willing to accept that. The whole time of file aspect is messy enough that my first instinct is to figure out if the feature is really worth implementing.

Anyhoo...  the easiest solution really is to have the web browser set a cookie or a session id with the local timezone when they log into your application. The server then passes that info to the date format routine and you're all set - you don't even have to maintain the timezone stuff yourself.
Friday, September 29, 2006
Specifically, from local time to utc, in Javascript, it would be...

d = new Date();
localTime = d.getTime();
localOffset = d.getTimezoneOffset() * 60000;

utc = localtime + localOffset;

And then if you wanted to go from that utc to New York City, which I think is eight hours behind...

offSet = -8;
nyTime = utc + (3600000 * offset);

...which is still in miliseconds, so you'd then use the date format library you'd like, or in Javascript...

nyTimeObject = new Date( nyTime );
alert( "Time is " + nyTimeObject.toLocaleString() );

...and so on.
Friday, September 29, 2006
Perl's DateTime and DateTime::TimeZone modules encapsulate these concepts well:
Chris Winters Send private email
Saturday, September 30, 2006

Thanks, that looks like just what I need for the Perl side.

I'll keep digging for the Python.
dot for this one
Sunday, October 01, 2006
Brian C, Lane Send private email
Tuesday, October 03, 2006

Thanks, that looks like just what I need.
dot for this one
Tuesday, October 03, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz