re: More on DateTime and TimeZones

S N — Wed, 21 Apr 2004 05:25:00 GMT

Hi,

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?

Thanks
Subbu

re: More on DateTime and TimeZones

RichB — Wed, 21 Apr 2004 06:08:00 GMT

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

re: More on DateTime and TimeZones

Paul Gielens — Wed, 21 Apr 2004 10:21:00 GMT

Hey Brad,

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

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

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.

re: More on DateTime and TimeZones

David — Fri, 23 Apr 2004 22:35:00 GMT

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....

re: More on DateTime and TimeZones

Anthony Moore — Thu, 06 May 2004 19:37:00 GMT

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.

re: More on DateTime and TimeZones

Markus Reiner — Mon, 17 May 2004 13:23:00 GMT

Hello,

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.

re: More on DateTime and TimeZones

Anthony Moore — Fri, 21 May 2004 18:35:00 GMT

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:

http://weblogs.asp.net/bclteam/archive/2004/05/21/136918.aspx

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.

.NET DateTime and Timezone: It Seems Simple, but It's Not

Mark Treadwell — Sat, 22 May 2004 02:37:00 GMT

Brad Abrams : More on DateTime and TimeZones

247Blogging — Tue, 20 May 2008 06:24:58 GMT

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&#8217;d put them into the mainfeed as I think they are generally interesting. I am a colleague of Brad's and I'm the

Brad Abrams : More on DateTime and TimeZones

Dating — Sat, 24 May 2008 03:43:09 GMT