A Brief History of DateTime [Anthony Moore]

MSDN Blog Postings · A Brief History of DateTime [Anthony Moore]

MSDN Blog Postings · A Brief History of DateTime [Anthony Moore] — Mon, 18 Jun 2007 20:02:57 GMT

PingBack from http://msdnrss.thecoderblogs.com/2007/06/18/a-brief-history-of-datetime-anthony-moore/

A Brief History of DateTime

DotNetKicks.com — Tue, 19 Jun 2007 01:14:16 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

re: A Brief History of DateTime [Anthony Moore]

Pete — Tue, 19 Jun 2007 01:48:23 GMT

Great post Anthony, thanks!

Thoughts:

(1)

<< DateTime is working just fine in the majority of existing uses>>

I don't think anyone thinks this is really the case. I think we'd all like to see APIs amended as soon as possible to support the new type.

(2) In the summary description of DateTime for intellisense, please can we have words to the effect that DateTime is effectively deprecated for many scenarios in favour of the new type. This would go a long way to preventing any more buggy .NET date/time code.

(3) Was there any consideration given in the design process around making DateTimeOffset an (immutable) reference type?

Pete.

re: A Brief History of DateTime [Anthony Moore]

lexp — Tue, 19 Jun 2007 01:51:34 GMT

1. What about System.TypeCode support? Are there any plans for TypeCode.DateTimeOffset ?

2. Are there any plans to support DateTimeOffset as a column type in SQL 2008?

3. Will DateTimeOffset be supported in XSD schemas and System.IO classes?

What can be possible issues with mass replacing DateTime to DateTimeOffset ?

re: A Brief History of DateTime [Anthony Moore]

chronos — Tue, 19 Jun 2007 04:34:31 GMT

While I appreciate your efforts, these solutions do not truly address the real problems.

I am also a customer and have been reporting my concerns and issues for many years.

I need a UTC-DateTime that *is a* DateTime. If I use DateTimeOffset, I will still need to convert it to DateTime when passing it as a parameter to existing methods. This introduces an opportunity for errors.

> "there is no practical way to do

> it without breaking compatibility."

Being a structure, extension is difficult. Could it be promoted to a class? Probably not a very good idea either. Ideally I would prefer an IDateTime interface, but then many existing signatures would need to be changed or it would be useless. Those changes could be done slowly overtime. But at least give us the interface and start addressing the real problem here.

As it is, we now filter through all source code searching for DateTime usage. Every instance is flagged as a potential bug (and usually is) needing special review. It is very timely and costly. Depreciating this poorly designed type would be very (*very*) appreciated. And depreciating it would also allow you to update signatures to use a new IDateTime interface.

I am also dissatisfied with TimeZoneInfo. It is a wrapper around OS timezone info. However, that OS support needs a manual update to be installed, and will need future updates as well. I can not assume that customers will have it or future updates installed. A better solution is to wrap something like

http://www.twinsun.com/tz/tz-link.htm . Caching the results for an appropriate amount of time should suffice. New data can be periodically downloaded. The user need not install anything, or even know anything about it. This is something that I can (and do) do on my own. However, integrating it into the framework library is difficult without any interfaces...

Please, design to interfaces. It would really solve so many issues.

re: A Brief History of DateTime [Anthony Moore]

Mike Griffiths — Tue, 19 Jun 2007 12:43:37 GMT

A well detailed and explanatory post that adds clarity to the DateTime enhancement and will help us full understand and apply the new type where required.

I think that you have made the right design decisions - not to break with backwards compatibility and to leave the existing type in place to serve in most applications. The new type will be welcomed however by developers building systems that run across time zones.

re: A Brief History of DateTime [Anthony Moore]

Bill Menees — Tue, 19 Jun 2007 15:26:22 GMT

This is one of the best posts I've ever read on MSDN blogs. It's extremely well written and informative. Thanks, Anthony!

FWIW, I totally agree that "DateTime is working just fine in the majority of existing uses". It works fine for my use cases, but it's good to know that the BCL team is working hard to handle other use cases as well.

re: A Brief History of DateTime [Anthony Moore]

Tom — Tue, 19 Jun 2007 17:47:17 GMT

>> Anthony Moore

Everyone here writes about IDateTime interface. BUT, everyone should be also aware that with current DateTime being Value Type, there would be a performance penalty caused by (un)boxing with methods expecting ref type (IDateTime) instead...

re: A Brief History of DateTime [Anthony Moore]

Anders Borum — Tue, 19 Jun 2007 17:50:59 GMT

I share the question by an earlier poster:

"Are there any plans to support DateTimeOffset as a column type in SQL 2008?"

Any thoughts on this? If not, what is the preferred way of storing and converting back to DateTimeOffset from a SQL column?!

re: A Brief History of DateTime [Anthony Moore]

Justin Van Patten — Tue, 19 Jun 2007 21:29:35 GMT

Pete,

1. We will incrementally start to add new APIs that use the new type and will consider changing existing APIs where appropriate.

2. This is a good idea that we will definitely consider.

3. Not that I'm aware of. I think we always had planned on the new type being a value type. One of the main goals we had when designing DateTimeOffset was for it to be largely substitutable with DateTime.

lexp,

1. There are no plans to add this to System.TypeCode. Could you explain your scenario for needing this?

2. DateTimeOffset is indeed a new column type in SQL Server 2008! We worked closely with the SQL team and both types are called DateTimeOffset and have the same internal layout.

3. DateTimeOffset will be supported in XSD schemas, although, I'm not sure whether or not this made it into .NET 3.5. Which System.IO classes are you referring to?

4. We've designed DateTimeOffset's members to be as similar to DateTime as possible, so it shouldn't be too hard to mass replace.

chronos,

You can create custom TimeZoneInfo instances with the static TimeZoneInfo.CreateCustomTimeZone method filling it with data from a copy of the Olson time zone database if necessary.

Anders,

As I mentioned above DateTimeOffset is indeed a new column type in SQL Server 2008! We worked closely with the SQL team and both type are called DateTimeOffset and have the same internal layout.

Thanks,

Justin Van Patten

CLR Program Manager

re: A Brief History of DateTime [Anthony Moore]

chronos — Wed, 20 Jun 2007 02:58:54 GMT

Tom,

> BUT, everyone should be also aware

> that with current DateTime being

> Value Type, there would be a

> performance penalty caused by

>(un)boxing with methods expecting

> ref type (IDateTime) instead...

Of course performance is important. However, more important than that is correctability and lack of bugs. DateTime as is broken. Anyone suggesting otherwise either has not worked with the type for long or is in denial. The problems are clear and have been written about extensively. That is why various solutions are being attempted. However, none of those solutions integrate well into the existing framework. For that to happen, there are only two options: 1) inheritance or 2) interfaces. Option 1 is not really likely for technical reasons. Options 2, while potentially being less performant, offers a solution without sacrificing backward compatibility. For those who are happy with the current DateTime, they may continue to use it without any performance lose. (I truly think they will end up regretting it one day when the bugs become known, though.)

This is not a solution. It only changes the problem a little.

re: A Brief History of DateTime [Anthony Moore]

chronos — Wed, 20 Jun 2007 05:14:13 GMT

Justin Van Patten,

> You can create custom TimeZoneInfo

> instances with the static

> TimeZoneInfo.CreateCustomTimeZone

> method filling it with data from a

> copy of the Olson time zone database

> if necessary.

I know. That was mentioned a few posts back. However, the real issue: how could it not be necessary? I can not assume that all users will have past and future updates installed. Therefore, I can not depend on the correct TZ information to be present on the system. Thus, I must ignore your data and always import the data via CreateCustomTimeZone.

Except for integration with TimeZoneInfo, I have been doing exactly that for a while. Once Orcas is released, I will need to port that over to your TimeZoneInfo implementation. Can the type be extended? Are there any interfaces to implement? Or will you tie my hands like with DateTime and absolutely force me to use CreateCustomTimeZone? I can probably guess the answers.

DateTime e DateTimeOffset

Marco Russo — Wed, 20 Jun 2007 12:12:08 GMT

Magari non è uno dei massimi problemi per chi lavora in Europa e generalmente ha a che fare con un solo

re: A Brief History of DateTime [Anthony Moore]

Andrew McCallum — Thu, 21 Jun 2007 01:35:15 GMT

Java had these problems 10 years ago, and you guys did not learn anything from it. They ended up deprecating most functionality in Date and moving it to Calendar. Why couldn't you have a DateTime object that optionaly has a null TimeZone property?

re: A Brief History of DateTime [Anthony Moore]

Johannes Hansen — Thu, 21 Jun 2007 11:35:12 GMT

Great post and great title... ;)

re: A Brief History of DateTime [Anthony Moore]

Michael Link — Thu, 21 Jun 2007 21:22:18 GMT

Great, insightful post about a difficult subject.

Andrew McCallum is right that Java had similar problems with their Date-Class. But worse they did it wrong the second time with the ugly Calendar class, I've never seen such an unintuitive Date-API. Luckily they started JSR 310 and I really hope they will integrate most of the design of the great Joda-Library.

UTCDateTime

Stephen Channell — Thu, 21 Jun 2007 21:26:37 GMT

Despite your well argued point, this is still looks like a nasty hack.

What do we do with a restless trader in Singapore executing a trade through a London app online to the NASDAQ in New York, and need to ensure we execute the trade within the Quote time.. what we need is a UTCDateTime from end-to-end that is only converted to local-time when we need to display it..

Universal Time is a Universal Standard!

re: A Brief History of DateTime [Anthony Moore]

chronos — Fri, 22 Jun 2007 02:38:13 GMT

Exactly my point, Stephen Channell.

While we can work with DateTimeOffset up to a point, it will need to be converted to a DateTime to work with existing APIs in the framework. It will be difficult if not impossible to avoid that conversion, which invites an opportunity for error and hence bugs.

What we really need is a UtcDateTime that *is a* DateTime. That may not be possible for technical reasons (value type), but if an IDateTime interface were to be introduced and all framework signatures were updated to use the interface, both backward compatibility could be preserved and those needing a UtcDateTime would be free to use it without need for conversion. It would integrate well with the framework, too.

re: A Brief History of DateTime [Anthony Moore]

Morten Mertner — Fri, 29 Jun 2007 04:56:30 GMT

I'd have to support chronos and Stephen Channell in that DateTimeOffset seems like a non-solution to the problem.

UTCDateTime is an intuitive concept and IDateTime would solve compatibility issues for future revisions.

re: A Brief History of DateTime [Anthony Moore]

Brian Anderson — Sun, 01 Jul 2007 13:18:42 GMT

I must agree with chronos, Stephen Channel, and Morten Mertner. DateTimeOffset is not a solution to the real problem. Backward compatibility can be preserved with the addition of an IDateTime interface while also providing a path towards a real solution: UtcDateTime, which would implement IDateTime.

Why is the blog's subtitle "Not actually a .NET blog"?

Noticias externas — Mon, 13 Aug 2007 17:17:47 GMT

Based on the feedback from my last CLR week ,

I think one CLR week a year is about right,

Welcome to

Why is the blog's subtitle "Not actually a .NET blog"?

The Old New Thing — Mon, 13 Aug 2007 17:57:05 GMT

CLR Week: A new annual tradition.

WebServices and Timezone

Bits&Bytes — Wed, 15 Aug 2007 08:02:12 GMT

Have you ever had to deal with consumer and provider of webservices residing in different time zones

TimeZoneInfo と DateTimeOffset

Days with .NET Framework — Mon, 03 Sep 2007 08:22:50 GMT

皆さん、こんにちは前回お約束した通り、少しずつではありますがTechEdでのDEMOのフォローをしていきたいと思います。今回は.NET Framework 3.5 で改善された TimeZone への対応について紹介したいと思います。今回、ご紹介するのは

TimeZoneInfo と DateTimeOffset

Noticias externas — Mon, 03 Sep 2007 08:40:39 GMT

皆さん、こんにちは前回お約束した通り、少しずつではありますがTechEdでのDEMOのフォローをしていきたいと思います。今回は.NET Framework 3.5 で改善された TimeZone への対応について紹介したいと思います

Celexa side effects.

Genunie celexa click here. — Fri, 11 Jul 2008 20:14:37 GMT

Celexa and aalcohol. Celexa and provigil. Celexa poids. Celexa and birthcontrol.

SQL Server 2008 For Developers

Jim O'Neil's Blog — Mon, 06 Oct 2008 05:18:31 GMT

This is the first of three postings I'm writing to follow up on the MSDN Events sessions I delivered