A Brief History of DateTime Follow-up [Anthony Moore]

re: A Brief History of DateTime Follow-up [Anthony Moore]

chronos — Fri, 13 Jul 2007 03:51:23 GMT

My main issue with DateTimeOffset is that it *is not a* DateTime and thus does not integrate well into the framework. Specifically, it can not be used in place of a DateTime but must be converted at various points. Ideally I would like to extend DateTime, but that is not possible. The only other solution is a common interface, but then many APIs would need to be updated to take advantage of that. (Backward compatibility could be maintained, though.)

For the most part, DateTimeOffset seems to have the required functionality. However, in the end I will still need to work with DateTime because it will not and can not integrate into the existing framework.

Honestly, I have created my own UTC-based DateTime wrapper. However, for the exact same reasons as DateTimeOffset, it too will not integrate into the framework.

This is the heart of the issue, and it is not being addressed.

re: A Brief History of DateTime Follow-up [Anthony Moore]

James Toodle — Fri, 13 Jul 2007 07:40:55 GMT

Regarding the point about value type vs. reference type for DateTimeOffset. The reason that I would prefer a reference type is solely so that I can extend the type to my own needs (assuming it were not sealed). Making it a value type without any interfaces denies me of that.

And on a similar note, I entirely agree with chronos. Because DateTimeOffset does not extend DateTime or implement any common interface, it does not fit well into the framework. It is little more than a wrapper that any of can create on our own. What we need from you, Microsoft, is a means to integrate that well into your framework. As the designers of a *common framework*, that should be a primary objective.

re: A Brief History of DateTime Follow-up [Anthony Moore]

Adam Mayers — Sat, 14 Jul 2007 15:36:31 GMT

I agree with the above posters. The type needs to fit well into the framework. That can be done with two methods: 1) type hierarchy (via inheritance) and 2) interfaces. You are not providing either. DateTimeOffset is nothing more than a wrapper around DateTime. The type does not suit my needs very well, so I have developed my own wrapper. It fits into the framework exactly as well as DateTimeOffset (ie, not at all). Either make DateTime inheritable (somehow) or provide a common interface. Anything else does not solve the fundamental problem.

re: A Brief History of DateTime Follow-up [Anthony Moore]

Phillip Green — Sun, 15 Jul 2007 12:57:10 GMT

I need an IDateTime interface too, but for slightly different reasons. I deal with a many BC dates. Unfortunately, the design of DateTime only permits dates from January 1, 0001 and up. While I have created my own implantation, it of course does not fit into the framework, and even worse, I can not even convert it to a DateTime type when needed.

DateTime is broken on so many levels. Provide us with a common IDateTime interface. Let us customize the type to our own specific needs. It was a poor design and it is time to fix it. The longer you wait, the harder it will be to deal with.

re: A Brief History of DateTime Follow-up [Anthony Moore]

Justin Van Patten — Mon, 16 Jul 2007 08:10:06 GMT

Thanks for the feedback everyone. We do plan to integrate DateTimeOffset throughout the Framework where appropriate. In .NET 3.5, we have taken the first steps by adding support for DateTimeOffset to XML Serialization and aligning the type with Microsoft SQL Server 2008. In the next version of the Framework after .NET 3.5, we plan to integrate DateTimeOffset more thoroughly throughout the Framework adding new overloads, methods, and properties where it makes sense to do so.

Thanks,

Justin Van Patten

CLR Program Manager

re: A Brief History of DateTime Follow-up [Anthony Moore]

chronos — Mon, 16 Jul 2007 11:26:49 GMT

Justin,

I do not mean to be rude, but you really are not comprehending the pains and difficulties that many of us are trying to convey.

1) DateTimeOffset does not extend DateTime or implement a common interface. Therefore it can be used as a replacement for the broken DateTime.

2) A default instance of DateTime is temporarily ambiguous. Ideally it should default to UTC. It can be manually set to UTC, but if ever forgotten, you have a bug which may not be so easy to find. The default DateTime is broken.

3) Conversion to DateTime is a potential source of error. If DateTimeOffset actually was a DateTime (via extension or a common interface), then no conversion would be necessary.

4) DateTime only allows dates from January 1st 0001. Custom types that fix this issue can not even be converted to DateTime when needed. No need for conversion if there was already a common interface.

5) The design of DateTimeOffset does not suite some developers. Yet you leave us with options for customizing it (extension, interface). Same for DateTime.

6) New overloads, methods, and properties for DateTimeOffset are not desired or needed. What is needed is overloads, methods, and properties for IDateTime.

Along with DateTime, DateTimeOffset is a complete of epic proportions. Provide us with an IDateTime interface and start updating signatures to use it. That is the only option to fix this terrible mess. And you can even maintain complete backward compatibility at the same time.

re: A Brief History of DateTime Follow-up [Anthony Moore]

Allan Michaels — Tue, 17 Jul 2007 05:06:11 GMT

Call me a realist or a pessimist, but this subject should not really surprise anyone. Just last year the HashSet<T> was announced without an ISet<T> or even an abstract Set<T>. Anyone who wants another set type is, well, screwed. APIs are being designed around HashSet<T> when they really should be coded to ISet<T>. Just like DateTime, we all lose.

Like it or not, Microsoft is building a framework for themselves, not for everyone else. Ideally they should keep this stuff internal instead of teasing us with partially designed functionality. In the end, we all will need our own implementations that will not "fit" into the framework.

A truly useful framework would code to interfaces. That would be a huge win for everyone. Unfortunately this does not happen enough with the BCL.

Something learned during the Whidbey phase: with few exceptions, once Beta 1 is released, it is generally too late to get these kinds of things changed. And Beta 2 is right around the corner.

re: A Brief History of DateTime Follow-up [Anthony Moore]

lexp — Thu, 26 Jul 2007 03:22:59 GMT

Interfaces are not a "silver bullet" to API usability problems. They are ideally fit when there can be multiple implementation of something very simple and obvious (for example, sorting).

DateTimeOffset is not a new implementation of DateTime. It is a combination of UTC DateTime and timezone offset. It can not be stored without data lose in datetime column in SQL Server or Oracle. And that's why it is not possible to abstract from DateTimeOffset and DateTime by using IDateTime interface.

re: A Brief History of DateTime Follow-up [Anthony Moore]

Adam Milles — Fri, 03 Aug 2007 08:41:39 GMT

After repeated experiences of frustration with the existing DateTime, I searched the web for help and found this page.

The problem that my team keeps running into it that DateTime is not always UTC. While we audit the code in an attempt to ensure that proper settings are consistently enabled, the team is large and some code inevitably slips through causing difficult to find and costly bugs.

Reading through the comments and some of the earlier posts, I really think that there should be a UtcDateTime type as others have suggested. However, it needs to integrate well into the framework, meaning that it will need to be a DateTime. At this late point in the game, the only option in some kind of common IDateTime interface.

DateTimeOffset does not seem to be what we need precisely because it is not a DateTime and does not share any common interfaces.

Unless you are going to depreciate DateTime and rewrite all existing related APIs, then DateTimeOffset is not a solution to the problem. An IDateTime interface, while requiring some API signature updates, seems to be an ideal solution moving forward to this really serious problem.

lexp,

Interfaces are not the "silver bullet" to API usability problems. However, in this case, it is precisely what is needed. DateTimeOffset is not be a new implementation of DateTime. And that is precisely why it does not solve the

underlining problems with DateTime. What I need is a UtcDateTime that is a DateTime. Inheritance and interfaces are the only solutions. Inheritance is not possible for technical reasons, so a common interface needs to be implemented: IDateTime.

SQL Server and Oracle are not part of the framework and are thus immaterial. There are solutions for storing UTC data in databases, but this is not the appropriate forum for such a discussion.

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

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

Based on the feedback from my last CLR week ,

I think one CLR week a year is about right,

Welcome to

WebServices and Timezone

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

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