Implementing date time related functions are sometimes becomes very tedious if you have internationalized web application which has users in different timezones. Simple “DateTime” data type is not sufficient when representing dates and times unless you go for conventionally to UTC. Even if you do it will introduce lot of nuances. Although DateTimeOffset does represent point in time unambiguously it does not indicate anything about user timezone. If the time zone has daylight saving rules (DST) things becomes really complicated. This becomes critical for online booking applications, online order processing applications etc. when indicating point in time especially relatively to different time zones in the world.
.NET framework provides two classes for TimeZones.
- TimeZone (Obsolete)
If you research on this in MSDN documentation found in https://msdn.microsoft.com/en-us/library/system.timezone%28v=vs.110%29.aspx has following warning….
Reason that System.TimeZone class not useful is its limited to local and UTC time zones which means it is not useful in many scenarios. For this BCL has new class named TimeZoneInfo which is introduced in later versions of .NET framework. Although this allows you to use Timezones found in the world, it’s TZDB is based on Microsoft, it is not based on IANA TZDB. IANA TZDB known to have following advantages,
- Historical accuracy since 1970
- Referenced by RFC and many other standards.
- TZDB is being frequently updated
- Widely implemented either natively or via libraries(for .NET what I am going to talk about) in programming languages and DBMS
At least from accuracy point of view it’s better to use IANA time zones over native timezones found in .NET There are many compelling reasons to use IANA timezones over Microsoft timezones even if there are few cosmetic convenient factors when using Microsoft timezones. To do so the library I used is “Noda Time”( http://nodatime.org). You can easily include it in your project via nuget. Not only the timezone issue probably more importantly it has many other benefits when doing datetime math over native types in .NET.
Noda time has a new structs(which are literally acting as datatypes) to represent point in time.
public struct ZonedDateTime : IEquatable<ZonedDateTime>, IComparable<ZonedDateTime>, IComparable, IFormattable, IXmlSerializable
These structs fills gaps found in .NET datetime related types. For example in .NET we don’t have “date only” data type.
would return datetime instance where time portion is in midnight. This has number of issues when it comes to TZDB rules. In Noda time you have time only and date only structs or literally data types. ZonedDateTime in noda time is all in one object where it has timezone, offset, the date and time. No equivalent is found natively found .NET framework. Even the datetimeoffset does not. What this means it is really safe to do date time related math on these types over .NET equivalent solution implementations. This is one other benefit you get with Noda Time.
Following is how you would associate particular date and time to an IANA timezone in Noda time.
LocalDateTime lt= new LocalDateTime(2015, 06, 02, 3, 3); DateTimeZone tz = DateTimeZoneProviders.Tzdb.GetZoneOrNull("Asia/Colombo"); ZonedDateTime slTime = lt.InZoneLeniently(tz);
Here local date time type in Noda time does not refer to local computers time. It just represents the given time. This is equivalent to DateTimeKind.Unspecified in .NET. In the latter I am associating it with Sri Lanka’s IANA time zone. Please note there are number of other ways you could construct point in date and time. Please refer to Noda time documentation. Noda time’s DateTimeZoneProviders used above also supports BCL timezones so which means you can use Noda time in your legacy application which uses MS timezones by considering many other benefits you get. You will find there are number of other benefits to use Noda time over native .NET date time types especially if you do serious datetime critical calculations.