Is modifying System.DateTime reasonable for a Time Zone/Offset aware DateTime object?

  • Article

So, in my previous "Designing Time Zone Conversion" post, a few readers asked whether we can update System.DateTime to understand Time Zones.

Before we look into whether we can update DateTime, we should look into how this "improved" DateTime should function. Users want a class that can specified a specific point in time. Some users had asked for a DateTime that acutally understands Time Zone. i.e. it is permanently associated with a Time Zone and applies the Time Zone rules as it changes, other users wants a DateTime that has an offset to UTC (i.e. not mapped to a Time Zone). Both feature requests are really asking for the same thing. A DateTime class that describe a particular point in time. Currently, DateTime can describe a particular point in time.. that is if you are describing it in UTC or in your local time zone. However, UTC is hard for people to work with; people do not think of their time in UTC. Only working in your local time zone is difficult too. Technology has basically shrunk the globe. People are attending meeting all over the world, or doing it over technologies like Live Meeting. Now, to design this new class let's look at the basic requirements:

- able to describe a single point in time unambiguously
- display the time in UTC, Local or other Time Zone or Offset.
- support functionality available in DateTime

Now, what about other scenarios that DateTime used to support? For example, describe a "date" with no time association or describe a "time" with no date associations. What if you don't know the time zone or offset? You just want to say "I have this Date and Time", sometimes you'll be working with a legacy application and they produce date time with no time zone associated with it. You need to be able to specify an "unspecified" Time Zone/Offset then. Now, how should this new DateTime object work between the two modes ("have a specific point in time" vs "not having it"?) How do you convert between the two modes? Would having 2 modes in one type be a good thing or would that just confuse users. If we have two modes, shouldn't we just have two objects? Since the two objects cannot easily interrop between each other?

These are just some consideration we have to consider before deciding whether we should make a breaking change and modify System.DateTime. Yes.... measuring how much we'll have to break is another consideration. Making DateTime be TimeZone/Offset aware will be a breaking change. What does DateTime.Kind means then? How should it act? How should the Add/Subtract functionality behave, what about Parse and ToString....etc. We need to ask these questions to each and every API DateTime support.

What do you think? Do you think it even make sense to update DateTime? How much "breaking" will you tolerate so that we modify DateTime to have this support?