views:

58

answers:

2

I'm using a shipping api (with fedex), and some of the fields I need to fill out ask for the datetime in a certain format (I've heard some people call it "zulu", it looks like this: 2006-06-26T17:00:00-0400) (by the way, what's a good way to format this in php)

I'm hoping to be able to do this by using zip codes. So if I know a user's zip code is 12345, and they say they want a package picked up between 9 and 12 in the morning, I can format that with the correct offset.

So, do I need to get the offset or timezone realted to that zipcode? I'm not sure I entirely understand the difference. Also, if they want in between 9 and 12, would I just have the time part of the timestamp say 9:00:00 along with the offset?

Thanks for any direction you can give.

A: 

For converting the zip code to a timezone, you're on your own unfortunately. However, a quick googling found me this, which may interest you:

http://www.webservicex.net/uszip.asmx

As for the formatting, you're in luck. PHP 5 has that date format built in:

date('c');
Mike Caron
Yeah, I actually tried out that webservice, but the problem is it kept giving me back single letters like "m" or "e". I know that those represent certain timezones around the world, but I'm pretty sure I was getting the wrong ones back.
Matthew
+4  A: 

Here is a source for a free dataset (Excel format) that maps zip codes and timezones as well as states and cities of course. Zip code is a good choice for granularity for matching to time zone and daylight savings changes because of special cases like the state of Indiana where different counties decide whether or not to observe daylight savings.

As far as implementing with this data: Read your FedEx API carefully. This has to be explicitly spelled out in their documentation. I'm guessing that all you really need to do is study up on the topic. Don't rush it. Take your time because you want to get this right the first time. I've been on several projects as a junior dev where the mgmt ignored timezones and paid a steep price later.

To get you started: Zulu time is a synonym of sorts for GMT and UTC, terms which all mean the similar thing and tend to be used interchangeably. When used, they mean that whatever date time is in question is somehow relative to a common point of reference which happens to run through Greenwich (and thus GMT = Greenwich Mean time.)

Whatever you do, however you store your data, make sure that you can always calculate zulu/utc/gmt from the value, or better yet, store zulu and just adjust the display for the client's timezone. There are several ways to go. Here is one. It's Sql Server specific but the concepts and strategies should be mappable to any type of db or persistent storage you're using.

For the last part of question, you should store both times individually. The word between implies two values and that's the right way to do it. Besides being more complete, this type of solution will help you address the case of "what if the start time is at 11:00 pm and the end time at 2:00 am on a daylight savings switch?"

Good luck!

P.S. Here is an interesting little read in an SO article. It's for the MS stack but interesting nonetheless and backs up some of my assertions. E.g. better to store the UTC/GMT and then convert... But read through the answers, they all have some valid points and are brief.

Paul Sasik
The international date line lies in the Pacific Ocean; the Prime Meridian runs through Greenwich. GMT and UTC (there is a difference but it is not significant for this discussion) is the time at Greenwich and does NOT change because of Daylight Saving Rules.
David Harris
@David: Good catch on the dateline. Not sure what I was thinking. I adjusted my answer accordingly.
Paul Sasik