DateTimeOffset: A New DateTime Structure in .NET 3.5 [Justin Van Patten]

re: DateTimeOffset: A New DateTime Structure in .NET 3.5 [Justin Van Patten]

MichaelGiagnocavo — Fri, 15 Jun 2007 00:57:16 GMT

What's wrong with just using DateTime to refer to UTC? In all our code we have DateTime, and it's always UTC (as is the timezone on all our servers). What am I missing?

re: DateTimeOffset: A New DateTime Structure in .NET 3.5 [Justin Van Patten]

chronos — Fri, 15 Jun 2007 02:58:07 GMT

Microsoft,

This DateTimeOffset type will not be sufficient. I need a DateTime (ie, something that extends DateTime), not something that can convert into a DateTime.

Please unseal the type and I will do the work myself.

re: DateTimeOffset: A New DateTime Structure in .NET 3.5 [Justin Van Patten]

Paul Bartrum — Fri, 15 Jun 2007 03:43:30 GMT

chronos, DateTime is a structure and thus cannot be inherited.

re: DateTimeOffset: A New DateTime Structure in .NET 3.5 [Justin Van Patten]

chronos — Fri, 15 Jun 2007 04:03:03 GMT

Then we need an IDateTime interface and _all_ signatures taking a DateTime will need to be depreciated and replaced.

re: DateTimeOffset: A New DateTime Structure in .NET 3.5 [Justin Van Patten]

Axel — Fri, 15 Jun 2007 06:10:52 GMT

I always use DateTime.UtcNow whenever I'm referring to an exact point in time.

re: DateTimeOffset: A New DateTime Structure in .NET 3.5 [Justin Van Patten]

Robert — Fri, 15 Jun 2007 07:08:30 GMT

Axel,

As do I. However, I have debugged code where specifying UTC was occasionally forgotten. It was a timely and expensive fix.

I want it to always be in UTC. Nor do I want to worry that my team will get it right. Why should I always need to make the same settings every time? A UTC-only type would be much more desired.

DateTimeOffset only complicates the situation further and is not an ideal solution. I agree that an IDateTime interface is needed.

re: DateTimeOffset: A New DateTime Structure in .NET 3.5 [Justin Van Patten]

Brian — Sat, 16 Jun 2007 12:04:37 GMT

Paul,

> DateTime is a structure and thus

> cannot be inherited.

In C# that is true, but certainly not in all other languages. Try to compile the following IL into a DLL.

.assembly Testing {}

.namespace Foo

{

.class public sequential unicode sealed beforefieldinit MyStruct

extends [mscorlib]System.ValueType

{

}

.class public sequential unicode sealed beforefieldinit MyStruct2

extends [mscorlib]System.ValueType

implements Foo.MyStruct

{

}

You may then use it from C#. (And I encourage you to examine the DLL in Reflector.)

There really is a strong need for a UTC-only DateTime type. Unsealing the type would be sufficient as I am comfortable writing IL. However, an interface is ultimately the better option. All of these new types being added in Orcas is only adding further complication without truely solving the real problem.

re: DateTimeOffset: A New DateTime Structure in .NET 3.5 [Justin Van Patten]

Brian — Sat, 16 Jun 2007 23:08:04 GMT

Not very good IL. This is better:

.assembly Testing {}

.namespace Foo

{

.class public sequential unicode beforefieldinit MyStruct

extends [mscorlib]System.ValueType

{

.method public hidebysig virtual instance void BaseMethod() cil managed

{

ret

}

.class public sequential unicode sealed beforefieldinit MyStruct2

extends Foo.MyStruct

{

}

However, when used in C#, the compiler throws CS0648 (type not supported by the language). It's legal IL, so C# should just consume it.

In any case, an IDateTime interface is really needed and is the best long-term solution.

re: DateTimeOffset: A New DateTime Structure in .NET 3.5 [Justin Van Patten]

Matthew — Mon, 18 Jun 2007 09:17:08 GMT

>> In any case, an IDateTime interface is really needed and is the best long-term solution.

I disagree. Better to make a clear distinction between the two types as has been suggested in the post.

re: DateTimeOffset: A New DateTime Structure in .NET 3.5 [Justin Van Patten]

Brian — Mon, 18 Jun 2007 11:04:09 GMT

Matthew,

A default DateTime is broken 100% of the time. Every single time it will need to be manually set to be UTC. Any exceptions, probably accidental, and often even due to ignorance or poor design, is a bug to be found and fixed. I have fixed dozens of these bugs over the last six years at several different companies. I have created wrapper types to help solve the problem. However, the best that can be done is wrap DateTime because it can not be extended and there are no interfaces to implement. I have also created my own non-wrapper types that provide the necessary functionality. However, it does not fit into the framework because of incompatible signatures.

While I have had many unpleasent encounters with this type in particular, the source of the problem is very prevalent throughout the BCL: 1) sealed types and 2) no interfaces. You can do better than this.

I am perfectly fine if Microsoft does not want to provide the functionality. But let me. To integrate that into the BCL, though, I will need to be able to either extend the type or implement an interface (appropriate signatures will need to take interface, the implementation).

re: DateTimeOffset: A New DateTime Structure in .NET 3.5 [Justin Van Patten]

Andy Mackie — Wed, 20 Jun 2007 10:12:35 GMT

Will DataSets support DateTimeOffset ?

We currently have the DateTimeMode property to control serialization of dateTimes from datasets. Although it has limitations, like you can't set it after you've loaded any rows, so it's a pain for untyped datasets - need to call FillSchema then Fill. And there were bugs with typed datasets - some claim these still aren't fixed in SP1 - see http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=208033&SiteID=1

So, will Datasets allow columns of type DateTimeOffset ? How would that work for untyped datasets where columns are created on the fly based on the SQL statement - do we need a "create dateTimes as DateTimeOffset's" property ? And could we specify a default timezone like UTC, or allow that to be picked up from a database column ? Whilst Oracle has a timestamp with timezone datatype which could map straight to DateTimeOffset, SQL Server doesn't, so how could we set default timezones in that case ?

I don't want to get into discussion about whether datasets are evil or not (personally I use objects) but lots of developers do use datasets, so it needs considering.

DateTime e DateTimeOffset

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

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

re: DateTimeOffset: A New DateTime Structure in .NET 3.5 [Justin Van Patten]

Tom — Wed, 20 Jun 2007 17:45:04 GMT

>> Justin Van Patten

Nope, that IL is not valid nor its metadata.

ILAsm compiles your Foo valuetype as sealed (even you do not mark it as sealed). If you compile it with "The Monster Flag" (/errors), you can create an unsealed value type. BUT such metadata are invalid. I hope Loader will refuse the assembly...

DateTimeOffset Guidance

Lazy Coder — Mon, 20 Aug 2007 11:27:05 GMT

" Anthony Moore has some guidance on when to use DateTimeOffset vs. DateTime: Use DateTimeOffset whenever...

What’s new in the .Net Framework 3.5 (Orcas)

Jack Gudenkauf (JackG) WebLog — Thu, 13 Sep 2007 21:32:03 GMT

Visual Studio (VS) 2008 and .Net 3.5, code named “Orcas”, will be released in the near future. This release

Nachlese: TechTalk - Visual Studio 2008 & .NET 3.5

Dariusz quatscht — Tue, 23 Oct 2007 02:30:50 GMT

Mein TechTalk ist nun zu Ende. Meine letzte Station heute in Berlin war Lustig und Amüsant, ich hoffe

.NET Framework 3.5 Now Available! [Justin Van Patten]

BCL Team Blog — Tue, 20 Nov 2007 03:39:56 GMT

.NET Framework 3.5 and Visual Studio 2008 have officially shipped! Soma has the announcement on his blog

.NET Framework 3.5 Now Available! [Justin Van Patten]

Noticias externas — Tue, 20 Nov 2007 04:12:43 GMT

.NET Framework 3.5 and Visual Studio 2008 have officially shipped! Soma has the announcement on his blog