Menu
The struct System.DateTime and its cousin System.DateTimeOffset have their structure layout kinds set to "Auto". This can be seen with:
typeof(DateTime).IsAutoLayout /* true */
or:
typeof(DateTime).StructLayoutAttribute.Value /* Auto */
or it can be seen from the IL which declares:
.class public auto ansi serializable sealed beforefieldinit System.DateTime
¯¯¯¯
Normally a struct (that is a .NET value type which is not an enum) written with C# will have layout "Sequential" (unless a StructLayoutAttribute has been applied to specify another layout).
I searched through some common BCL assemblies, and DateTime and DateTimeOffset were the only publicly visible structs I found with this layout.
Does anyone know why DateTime has this unusual struct layout?
475
The actual data in a DateTime is a single long integer. If it were a class, every time you created a new object, 8 bytes would be allocated on the heap and another 8 bytes would be allocated on the stack for the pointer. So by making a DateTime a struct, it effectively cuts the memory requirements in half.
The DateTime value type represents dates and times with values ranging from 00:00:00 (midnight), January 1, 0001 Anno Domini (Common Era) through 11:59:59 P.M., December 31, 9999 A.D. (C.E.) in the Gregorian calendar. Time values are measured in 100-nanosecond units called ticks.
DateTime is a Value Type like int, double etc. so there is no way to assign a null value. When a type can be assigned null it is called nullable, that means the type has no value. All Reference Types are nullable by default, e.g. String, and all ValueTypes are not, e.g. Int32.
DateTime is a struct . Which doesn't mean it can't have many different constructors and methods and overloads.
This is going to require speculation, this decision was made a long time ago, well before .NET 1.0 shipped. The attribute on System.DateTime is at best a micro-optimization, not uncommon in .NET code. It is somewhat appropriate, the struct has only one field so there's never any issue with layout. The ones for the internal CustomAttribute structs were probably done by the same programmer. Doesn't matter either, unmanaged code never sees them.
The one for System.DateTimeOffset was done much later and almost certainly a copy-paste bug.
That programmer got away with it, no reason for the CLR to re-arrange the layout from the sequential version. Re-arranging with auto-layout occurs when the struct contains padding between fields that is large enough to fit another small field. Not the case for DateTimeOffet.
Some odds you'll get a Microsoft guru to pay attention to this when you file a feedback report for DateTimeOffset. It is wrong afaik. Post it to connect.microsoft.com
86
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
