More on DateTime and TimeZones

We got some great feedback from this entry on DateTime.  The dev lead for the BCL took time to post to my comments, but I thought I’d put them into the mainfeed as I think they are generally interesting.  


I am a colleague of Brad’s and I’m the development owner of DateTime. I wanted to respond to the feedback on this thread, particularly the excellent feedback from Douglas Husemann (here) and Jeremy Gray (here).


Serialization in XML is the number 1 complaint associated with the DateTime. It is definitely something we are committed to fixing in Whidbey.


There may be a misunderstanding, but there is no current plan to introduce a new “Date” data type to the System namespace. It is important to keep the number of distinct data types in the System namespace small because so much code needs to special-case it. The DateTime class was designed to meet the scenarios associated with a Date, a Time and a combined Date and Time. There are cases in the rest of the framework where some formatting options effectively preclude the usage as a stand-alone Date which we will be correcting in Whidbey. The use of the “zzz” format by XML Serialization, XML Convert, and DataSet is the most extreme example of this because this format is only valid in cases where the time is significant and the time is Local. It precludes Date-only and UTC scenarios. If we could wind the clock back to before shipping V1.0 we would have left the “zzz” format off when serializing DateTime.


Regarding the request for a servicing release. Introducing new functionality into our V1.0 and V1.1 releases is always significantly more risky and expensive than a regular release. Feedback such as you are providing here is very useful in convincing people that the extra cost and risk is justified. In fact the more specific business impact and adoption impact about this issue from as many distinct sources as I can get is useful in trying to get all the right teams and individuals bought in that this work should be done. If you know others impacted by this, or you can provide more information about its impact on you, that would be helpful in making something happen. Please contact me ( if there is more feedback you can provide..


Regarding compatibility: the only circumstances when I see customers significantly more inflamed than you are right now about this is not when we have bugs in our product, but when fixing bugs causes reasonably functioning code to break. And compatibility issues often go directly to impacting your users and customers as they upgrade their operating systems or runtimes, or even when they install service packs. Unfortunately, it is easy to take a dependency on the weird way DateTime serializes in XML, so we have to be very careful about how we introduce fixes in Whidbey, and we have to be even more careful about anything we consider in servicing, which has an even higher compatibility bar.


Requests for a “historical” DateTime have been very infrequent. We are unlikely to provide such a thing in the Longhorn timeframe due to lack of demand. There may be a good 3rd party opportunity for a library for historical dating that interoperates well with the DateTime class.


I will pass on the request for more calendars to the team that owns that area.


I am not clear about your request for a more culturally aware DateTime. This FAQ may be of help in finding ways to do this with the current framework:


Comments (10)

  1. S N says:


    Another issue related to this DateTime one. In my application I need to keep track of changes made to the system clock. In other words, whenever the system clock is modified either through program or user, I need to do some tasks so that certain time sensitive tasks can function properly.

    Right now, this event is captured by the DataTime class. But it doesn’t expose any interfaces so that the CLR application can also hook in to this event.

    Could this be taken care in the future?



  2. RichB says:

    Does Whibey implement BCE dates? This is one area I miss greatly.

  3. Paul Gielens says:

    Hey Brad,

    I’m sorry to say, but you know what really, really bothers me?


    Serialization in XML is the number 1 complaint associated with the DateTime. It is definitely something we are committed to fixing in Whidbey.


    So what am I supposed to do with my 1.0/1.1 code base, just live with this bug. I asked Dare something similar with no response thus far. We don’t care about Whidbey, we care about delivering solutions on 1.0/1.1. For most companies Whidbey is distant future.

  4. David says:

    How does DateTime handle pure dates at this point? With that I mean dates that have no time information attached, i.e. not just a DateTime of 4/21/2004 00:00 where the time part is just omitted in the UI.

    A great example of what I mean is Outlook: There you can save a birthdate for a contact. The UI shows a date only, but internally it seems that it is saved with time information. If you then switch your time zone (traveling etc.) Outlook shows wrong birthdates. Can’t tell you how much problems that has caused for me already!! If Outlook would save the birthday as a date without any time information the problem would probably not show up. By the way: If you know anybody from the Outlook team please tell them that this is REALLY bad 😉

    How would I prevent something like that with the DateTime class? Is there a way to set a flag that a specific instance should ignore the time part or something like that? That would seem quite weird to me…. I think conceptually there is a big difference between a DateTime and a Date type: The latter does not represent a specific point in time, while the former does….

  5. Thanks for the feedback here. I’ll try to respond to each of the points raised in turn:

    This is the first time I’ve heard a request for change notifications when the system clock changes. We will track that as a feature request, although we have many hundreds of them, so multiple distinct requests help. There will not be a solution to this in Whidbey, although there may be Win32 events you can respond to here.

    Whidbey will not have a solution for Before Common Era dates, and it would be fair to say that the main DateTime cannot support this because we can’t make it any bigger and we have no spare bits. A solution would best come in the form of a new class, such as a HistoricalDateTime that can go back 10,000 years or so, that can also interoperate with the existing DateTime class. I’m hearing a few requests for this, so we will pass this on. It might be a good academic partnership idea.

    The feedback on needing a fix for the XML Serialization problem sooner than Whidbey is useful. I can use this feedback reaction in trying to sell this internally.

    Regarding David’s post: You are right that getting a time zone conversion when you don’t want it is a big problem. One way to have dealt with it is by having a separate type dates with and without types, as you suggest. However, a just as effective way to deal with it would be to have the serializers move the data around without doing this conversion unless you ask for it specially. This also gives you the advantage of being able to serialize UTC dates correctly, which are more reliable dates to work with anyway.

    The whole serialization problem that .NET and Outlook have is not because they joing date and time together, but because they assume times are always local. If we could wind the clock back, we would just remove the time zone offset and do no conversion when serializing. This would allow both UTC and date-only DateTime instances to work correctly. Local DateTime instances would not have worked, but it would have been much easier to ask people who needed that to "opt-in" to that behavior by doing the conversions themselves, than forcing everyone into this behavior and providing no way to opt-out.

    Our solution in Whidbey will be to let you differentiate between Local, UTC and unspecified dates (e.g a date of birth) and serializing according to the type of date. This enables all these scenarios without needing a whole new data type.

    We are still looking at whether anything will be done for V1.1. My opinion is that we should just provide a configuration switch to stop using the time zone formats so that the dates just move around verbatim, which would enable the UTC and date-only scenarios just fine.

  6. Markus Reiner says:


    we have also problems with DateTime because of using local time. IMHO DateTime should internally use always UTC. Only Parse() and ToString() (the methods converting it for interacting with a user who lives always relativ to local time) should ask the OS and convert it if needed.

    If someone persists a DateTime instance (to a file, to registry and so on) you will always get in trouble! Don’t look only at serialization!

    It would be very helpful if we could have a patch for .NET 1.1.

  7. Markus, thanks very much for the feedback. I have been working on some FAQ entries to answer these questions, which for now I have posed on the BCL Blog:

    In short, it is not practical to make a change as substantial as you are recommending to DateTime, either in servicing or in future releases. Beleive me, the options have been thoroughly explored, but it is not possible to get acceptable compatability in terms of both functionality or performance. The first FAQ entry goes into the detail on this issue.

    However, it is possible to serialize DateTime without getting into trouble, so two of the FAQ entries are devoted to recommended ways to serialize DateTime in Binary and Text.

    Thanks very much for your response and I hope this is helpful.

  8. 247Blogging says:

    We got some great feedback from this entry on DateTime. The dev lead for the BCL took time to post to my comments, but I thought I’d put them into the mainfeed as I think they are generally interesting. I am a colleague of Brad’s and I’m the

  9. Dating says:

    We got some great feedback from this entry on DateTime. The dev lead for the BCL took time to post to my comments, but I thought I’d put them into the mainfeed as I think they are generally interesting. I am a colleague of Brad’s and I’m the