Even more on DateTime…

I thought I’d promote some of the discussion from a recent blog entry to the main feed as others may find it interesting…  As Mark Treadwell says, it is a complicated subject. 


Comment (Markus Reiner):

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.


Response (Anthony Moore)

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. Believe me, the options have been thoroughly explored, but it is not possible to get acceptable compatibility 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.

Comments (3)

  1. James Hancock says:

    My biggest problems with DateTimes are that there is no DateTime.Empty so the DatePicker control can’t do nulls and it’s horrible about doing database things so you have to check for null all of the time before you put it into a variable, and #2 is that UTC isn’t constant.

    So If I store the UTC value in a database for a time and then retrieve it, it will be fine, until I want to pull it out later and there has been a daylight savings shift. Then doing DateTime.ToLocal() results in a different value than what I was expecting, because it was stored in the database when there was no daylight savings and then pulled out when there was resulting in the hour discrepency.

    I really wish there was a way to store a time in a database so that when it gets pulled out, it will always be the exact right time, adjusted for Daylight savings time. Anyone have any suggestions? (I know this is a variation on the question asked above, but it’s slightly different)

    Our solution so far as been, since we don’t care about the date because it’s stored in another field, to just store an integer value that is hours from midnight in UTC and then always calculate the Local time as if it was January 1st (times get pushed into the database as if it was January 1st too)

  2. ShadowChaser says:

    Being a lotus notes developer (as well as a .NET developer), I have a *lot* of experience with UTC dates – Lotus Notes’ data storage only supports them (you cannot just have local time).

    While I realize everyone is begging for UTC dates – in many cases it can be a horrible solution and introduce just as many new problems.

    Take this scenario, for example. A developer wants to *only* store a date. In the application we develop at my workplace, we store data for governments – specifically for restaurant inspections. The inspection’s date is a fixed point in time – the "time" is tracked seperately.

    Of course, most development frameworks and apis (.NET included I believe) do NOT support just a "date" variable – it stores the time as well. When you only store a date, generally the time is reset to midnight. With UTC dates, the system., in most cases, automatically modifies the date to the local time – the problem? It changes the day! Because our servers are located in a different time zone than the end user’s client application, the dates "roll back" to the previous day on our servers!

    This means that all of the reports we generate on our servers from that datastore have inaccurate dates – not a good thing when you are dealing with government data!

    While it seems like a noble cause to think of a date as a fixed point in time within the universe, about half of the time you’re actually talking about the *calendar* date – which is a completely different thing.

    I would think that if you want to add UTC dates – you should also add two more data types – one for dates only and one for times only. At very least, a "date only one".

    Is there ANY way a DateTime.Empty can be added safely? As ome of the other people commenting here pointed out, its a major hassle having to create two fields for every date time value – one for the actual value and another for an "valid/invalid" state. It’s very nasty! I realize it would be a breaking change, but would it really affect *so* many developers if you increased the datetime minimum by one second and used that reserved space as the .Empty? How many applications can *really* say they need to store a date/time value of midnight January 1, 0001 anyways? 🙂

  3. JD says:

    ShadowChaser, if a hypothetical new DateTimeUtc class were added, it would NOT do the automatic ‘convert to local’ behavior that is the root of the problem you describe. So the retrieved UTC time would still be at midnight of the given date, so the date would be preserved.