7

In the .Net framework DateTime structure, the Year is defined as an int (which is really A System.Int32). However, the MSDN documentation says that the value will always be between 1 and 9999. Thus, a ushort (System.UInt16) is more than adequate to store the value and takes up half the space. So why is it an int and not a ushort?

There is an implicit conversion from ushort to int so there is no casting that needs to be done to do integer arithmetic on the Year.

I realize this is a micro-optimization issue and thus not very important. I am just curious.

epotter
  • 7,631
  • 7
  • 63
  • 88
  • 2
    It is *not* an optimization. Bottom of http://stackoverflow.com/questions/10065287/why-is-ushort-system-uint16-ushort-equal-to-int-system-int32/10157517#10157517 – Hans Passant Jun 21 '12 at 15:11
  • Even with a `ushort`, we'd be wasting the top two bits... – AakashM Jun 21 '12 at 15:15

2 Answers2

4

Thus, a ushort (System.UInt16) is more than adequate to store the value and takes up half the space.

Where do you think that "space" is being wasted? DateTime doesn't store each component in a separate field anyway. If you're storing the year somewhere, feel free to cast it to a ushort - and cast Month to a byte, etc.

Note that ushort isn't CLS-compliant, which is probably the reason for it. There are a lot of properties which would make sense to be unsigned, such as string.Length etc... but the framework tries to be CLS-compliant where it can.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
0
  • unit returns a Unsigned 16-bit integer
  • Int returns a 32-bit integer.

I am assuming that the JIT Compiler takes advantage of the CPU architecture and therefore processing at 32bit would be more efficient than 16bit. I believe there was a similar debate with VB6 when using Integers vs Longs (Bytes allocated vs Architecture Speed).

http://blogs.msdn.com/b/davidnotario/archive/2005/08/15/451845.aspx

Darren
  • 68,902
  • 24
  • 138
  • 144