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

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?

Comments

• Anonymous
  September 04, 2006
  You should mention these links for reference:
  http://blogs.msdn.com/bclteam/archive/2004/05/21/136918.aspx
  http://blogs.msdn.com/bclteam/archive/2004/06/01/145487.aspx
  
  I want DateTime to always, without exception, be in UTC.
  Yes, it will be a lot of work to fix now, but it is always a lot of work to work around the current implementation, too.
  (Yes, I know that I can manually specify it myself in 2.0.)
  
  Please create an IDateTime interface and make DateTime implement it. Then modify the signatures to use IDateTime.
  That way I can replace your type with my own UTC DateTime class. Also, it will give you more room for future changes, maybe even replacing the entire type someday.
  You really should replace it someday. At least give yourself some room to work.
  
  Assuming it's already in UTC, computing the timezone offset manually isn't too difficult. But having it built in would be useful.
  (Do not confuse time zone and daylight savings.)
  
  DateTime has always been broken. Break it as much as needed to help fix it.
  
• Anonymous
  September 04, 2006
  The comment has been removed
• Anonymous
  September 04, 2006
  I'm with Michael on this in that DateTime should remain as is.
  
  Perhaps what is needed is a ZonedDateTime class that wraps DateTime and a region/offset indicator.
  
  When somebody does zonedDateTime1.Subtract(zonedDateTime2) the class could do something like;
  
  public class ZonedDateTime {
  public DateTime LocalDateTime;
  public Decimal HourOffsetFromUTC;
  
  public ZonedDateTime(DateTime localDateTime, Decimal hourOffsetFromUTC) {
  LocalDateTime = localDateTime;
  hourOffsetFromUTC = hourOffsetFromUTC;
  }
  
  public DateTime UTCDateTime {
  get { return LocalDateTime.AddHours(HourOffsetFromUTC); }
  }
  ...
  public Subtract(ZonedDateTime otherDateTime) {
   DateTime newDateTime = UTCDateTime.Subtract(otherDateTime.UTCDateTime).Subtract(HourOffsetFromUTC);
   return new ZonedDateTime(newDateTime, HourOffsetFromUTC);
  }
  }
  
  The only changes then needed to DateTime might be to pop out a ZonedDateTime class - i.e. nothing breaking.
  
  [)amien
• Anonymous
  September 05, 2006
  My last post was about investigating on how to improve on System.TimeZone so that we have better support for all the time zones. The comments left by users in that post asked for a DateTime that understands Time Zone, that why I thought this is worth discussing about.
  
  I agree with you guys that the first problem is with System.TimeZone. However, does System.DateTime needs to be fixed as well?
• Anonymous
  September 05, 2006
  The comment has been removed
• Anonymous
  September 08, 2006
  The comment has been removed
• Anonymous
  September 10, 2006
  grauenwolf,
  
  Why do you record the time in Pacific Time?
  Your situation sounds ideal for UTC.
  Store everything in UTC, and only at presentation time offset the value to whatever timezone your user is at.
  While Microsoft could make it a little easier, the offset calculations could hardly be any easier to calculate manually.
  
  I treat any non-UTC DateTime as a bug.
  
• Anonymous
  October 03, 2006
  Strongly agree with those in favor of UTC. Your application should never ever ever store a non-UTC DateTime. If you need to display a DateTime to a user, you can do the conversion at runtime to display to the user - but never store a non-universal time and never transmit a non-universal time out of the process.Brilliant analogy to Point. I couldn't have said it better.
• Anonymous
  October 03, 2006
  Didn't I say it two weeks ago that API naming is the most difficult thing? :) My BCL post on System.TimeZone2