Why is DateTime.Now.Year int and not ushort

In the structure of DateTime Framework.Net Year is defined as int (which is really System.Int32). However, the MSDN documentation states that the value will always be between 1 and 9999 . Thus, ushort (System.UInt16) is more than enough to hold the value and takes up half the space. So why is it int and not ushort?

There is an implicit conversion from ushort to int, so there is no caste that needs to be done to perform integer arithmetic in Year.

I understand that this is a micro-optimization problem and therefore not very important. I'm just curious.

+7
source share
2 answers

Thus, ushort (System.UInt16) is more than enough to hold the value and takes up half the space.

Do you think that β€œspace” is disappearing? In any case, DateTime does not save each component in a separate field. If you are storing a year somewhere, feel free to transfer it to ushort - and pour Month into byte , etc.

Please note that ushort not CLS-compatible, which is probably the reason for this. There are many properties that make sense to be unsigned, such as string.Length , etc., but the structure tries to be CLS-compatible where possible.

+4
source
  • returns a 16-bit unsigned integer
  • Int returns a 32-bit integer.

I assume that the JIT compiler takes advantage of the processor architecture, and therefore processing on 32-bit will be more efficient than 16-bit. I believe that in VB6 there was a similar debate when using Integer vs Longs (bytes allocated against architecture speed).

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

0
source

All Articles