First published on MSDN on Mar 25, 2016
This is not an Azure-specific issue and it is certainly not a new issue but I was inspired after reading A story about timestamp and timezone on Commitstrip.
I am not sure if others are experiencing this but as I am working more and more in Azure; my engagements are shifting from large corporations to medium and small organizations. In general I am finding the uptake of Azure in New Zealand and Australia to be more widespread when the company has less of an investment in existing infrastructure and/or existing governance preventing the adaptation of new technology. This also means the type of solutions that I am involved with building are also shifting from regional enterprise solutions (e.g., financial, medical, etc.) to global bespoke solutions (e.g., eCommerce). The issues surrounding timezones and culture have always been there but I am seeing more confusion and defects in the projects that I am involved with. In most cases some planning and design early in the project could have avoided these issues. Well, at least reduced their impact.
Please comment if you are or not experiencing something similar or do not agree with some of my assumptions.
So what is the big deal?
It is easiest to show using an example. The following is a simple page that renders a customer model at the client (javascript) and at the server (razor):
That was what the developer saw when the project was run locally but once it was deployed to Azure, things changed:
Several defects are then raised as the date format changed and to the test team the date is incorrect. I have not met a test team that accepts the argument that the date is ok as it is just showing UTC. In simple terms, the server is running in another timezone and culture. This is also not a ASP.NET or MVC specific issue as it is a consideration for other Azure resources like SQL Azure and worker roles.
Tip 1: Pass date objects and not strings
When passing data to/from the server, it is generally best to leave the date as an object. In most cases this simplifies things as the server can pass the object to other objects without requiring additional conversion and/or needing to worry about what timezone the request originated from.
But there are always exceptions... For example, what if the date being sent in refers to a date in another timezone? For example, when ordering a product you might want to specify the shipping date for a warehouse in Nebraska but you are ordering from the Ukraine. In this case, keeping the date as a string and performing this conversion on the server might make the most sense.
Tip 2: Establish a pattern and stick to it!
There are many existing libraries to help with handling timezones. Spend the time early in the project to research some libraries and establish a suitable pattern for the team. You might find that the skillset of the team is heavier in MVC than javascript so you invest in additional MVC packages as opposed to javascript packages. The main thing is the industry has been tackling this issue for many years so reinventing a solution is most likely not in the interest of the project.
Here are some javascript libraries and posts that are worth looking into:
Here are some MVC libraries and posts that are worth looking into:
Tip 3: Consistency
Once an approach is agreed upon then adopt it across the solution. Sounds simple but it is surprising the number of times that pages are only looked at after they fail testing. Unit tests and code reviews are a great approach to helping with consistency.
Summary
Again, not a new problem and not specific to Azure but with a little planning and discipline, managing dates is relatively simple to address. It is surprising the number of times development teams get into trouble with this though and the number of times some unfortunate developer has to go in front of the steering committee to say they need more time because the dates are not accurate.
Please post additional tips and/or libraries in the comments.
Additional Note
Mark Russinovich covers some best practices at Build2016 in Building Resilient Services: Learning Lessons from Azure .
Authored by Jeffrey Chilberto
This is not an Azure-specific issue and it is certainly not a new issue but I was inspired after reading A story about timestamp and timezone on Commitstrip.
I am not sure if others are experiencing this but as I am working more and more in Azure; my engagements are shifting from large corporations to medium and small organizations. In general I am finding the uptake of Azure in New Zealand and Australia to be more widespread when the company has less of an investment in existing infrastructure and/or existing governance preventing the adaptation of new technology. This also means the type of solutions that I am involved with building are also shifting from regional enterprise solutions (e.g., financial, medical, etc.) to global bespoke solutions (e.g., eCommerce). The issues surrounding timezones and culture have always been there but I am seeing more confusion and defects in the projects that I am involved with. In most cases some planning and design early in the project could have avoided these issues. Well, at least reduced their impact.
Please comment if you are or not experiencing something similar or do not agree with some of my assumptions.
So what is the big deal?
It is easiest to show using an example. The following is a simple page that renders a customer model at the client (javascript) and at the server (razor):
That was what the developer saw when the project was run locally but once it was deployed to Azure, things changed:
Several defects are then raised as the date format changed and to the test team the date is incorrect. I have not met a test team that accepts the argument that the date is ok as it is just showing UTC. In simple terms, the server is running in another timezone and culture. This is also not a ASP.NET or MVC specific issue as it is a consideration for other Azure resources like SQL Azure and worker roles.
Tip 1: Pass date objects and not strings
When passing data to/from the server, it is generally best to leave the date as an object. In most cases this simplifies things as the server can pass the object to other objects without requiring additional conversion and/or needing to worry about what timezone the request originated from.
But there are always exceptions... For example, what if the date being sent in refers to a date in another timezone? For example, when ordering a product you might want to specify the shipping date for a warehouse in Nebraska but you are ordering from the Ukraine. In this case, keeping the date as a string and performing this conversion on the server might make the most sense.
Tip 2: Establish a pattern and stick to it!
There are many existing libraries to help with handling timezones. Spend the time early in the project to research some libraries and establish a suitable pattern for the team. You might find that the skillset of the team is heavier in MVC than javascript so you invest in additional MVC packages as opposed to javascript packages. The main thing is the industry has been tackling this issue for many years so reinventing a solution is most likely not in the interest of the project.
Here are some javascript libraries and posts that are worth looking into:
Here are some MVC libraries and posts that are worth looking into:
- Useful stackoverflow post
- MSDN Formatting Date and Time for a Specific Culture
- Nuget Globalization package - beta
Tip 3: Consistency
Once an approach is agreed upon then adopt it across the solution. Sounds simple but it is surprising the number of times that pages are only looked at after they fail testing. Unit tests and code reviews are a great approach to helping with consistency.
Summary
Again, not a new problem and not specific to Azure but with a little planning and discipline, managing dates is relatively simple to address. It is surprising the number of times development teams get into trouble with this though and the number of times some unfortunate developer has to go in front of the steering committee to say they need more time because the dates are not accurate.
Please post additional tips and/or libraries in the comments.
Additional Note
Mark Russinovich covers some best practices at Build2016 in Building Resilient Services: Learning Lessons from Azure .
Published Feb 12, 2019
Version 1.0