With an ecosystem of devices that is constantly evolving, it’s hard to predict who will consume your REST APIs and how they will consume them. Devices as we know them are changing shape, consequently applications are constantly adapting to new platforms.
Lets face it, mobile apps are the norm and shouldn’t be ignored. They travel and shouldn’t be considered as sedentary.
Imagine a scenario where you are on a business trip and try to fetch today’s news from a different continent. Your device formulates a URI with a date and calls a service… no results…
That’s weird! Its 10 PM and I should get results for today’s news. This is probably the moment where you realize that you aren’t in your normal time zone… your phone has adapted to your new geographic location but the APIs the app is calling has not!
The point I’m trying to make here, is that time zones matter.
This is especially true when you are working on Windows Azure, because it’s configured to run in UTC (Coordinated Universal Time). Calling a REST API that require dates and times as parameters is quite common and to be able to consume them you need to convert DateTimes to the provider’s time zone. Otherwise you may end up with unexpected results. I strongly recommend to standardize your REST APIs by considering UTC (Coordinated Universal Time) throughout your design and implementation efforts.
Here’s a guaranteed headache! Imagine that one of your APIs is in Tokyo Japan (GMT +9) and the second API is in
Montreal Canada (GMT -5 (-4 during Daylight Savings)). Your Cloud Services are hosted in Windows Azure (GMT 0).
Your Cloud Service has to take into account different time zones for each of the APIs it calls. Furthermore, Montreal Canada has Daylight Savings, that means that it’s time zone shifts twice a year! Both APIs are 13 to 14 hours a part…
What a headache!
Standardizing DateTimes will reduce bugs, headaches and accidental complexity. Build for consistency.
Food for thought, should we use the W3C Standard Date Time format YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00) in our REST APIs?
Read More About Working With Time Zones on Windows Azure
- Using Quartz.Net to Schedule Jobs in Windows Azure Worker Roles
- Are You Getting a 403 (Forbidden) From Windows Azure Storage Services?
- Midnight Universal Time is not Midnight Local Time!
- Running Code on Windows Azure? Set the time zone of your development machine to UTC (Coordinated Universal Time)!