为什么在C＃中没有System.DateTime的“约会”速记？
如int ， long ， ushort ， uint ， short等。
为什么没有System.DateTime的简短指针？
许多类型与C＃中的“速记”关键字相关联; 例如，
System.Int32也可以写成int而System.String可以写成string。 为什么没有System.DateTime的简写？
在我回答这个问题之前 – 或者更确切地说，没有回答它 – 让我们首先注意C＃中有简写的类型。 他们是
object string sbyte byte short ushort int uint long ulong char bool decimal double float
我先谈谈其他一些答案。
Mystere Man正确地注意到这些关键字中有几个来自C; C有int和相当冗长的unsigned int ， double和其他几个。 然而，C最值得注意的是没有bool ， long ， decimal ， object或string 。
我认为我们可以合理地说，包含关键字int和char等的一个理由是熟悉C和C ++的用户可以在C＃中快速生产。 这里的目标是让C程序员熟悉关键字，但这些关键字的目的绝不是像C中那样具有相同的语义。例如，C没有指定任何关键字的大小。强烈鼓励int成为机器的“自然尺寸”。 C＃确实指定了每种类型的确切大小和范围。
所以我认为我们不能合理地说没有 System.DateTime简写的理由是因为C中没有.C中也没有string或decimal 。
Jason指出DateTime不是“C＃语言的一部分”，因此没有关键字。 但那是彻底乞求的问题！ 问题基本上是“好的，那么为什么DateTime不是C＃语言的一部分？” 以一种需要回答同等难度问题的方式回答问题被称为“乞求问题”，这个问题已被彻底乞求。
考虑什么是“基本”类型是有益的。 除了decimal之外，所有在C＃中具有关键字的类型在某种程度上都是“非常特殊的”。 也就是说，底层运行时具有内置于object特殊行为，显然，因为它是通用基类型。 string可能只是一个char数组，但它不是; 字符串很特别。 （因为它们可以被实现，它们可以是常量，它们可以存在于元数据中，等等。）整数和二进制浮点类型都具有内置于框架中的特殊处理操作。
但System.Decimal只是另一种结构类型; 它是128位整数和大量用户定义的运算符。 任何人都可以实现自己的十进制算术类型。 但“祝福” System.Decimal使其成为C＃语言的一部分意味着即使其转换是作为方法实现的，我们也将它们视为内置转换 ，而不是用户定义的转换 。
decimal确实是一个奇怪的。 它不是运行时的“基本”类型，但它是一个关键字。
这引出了一个有趣的观点。 System.IntPtr和System.UIntPtr *是运行时的基本类型。 它们是“指针大小的整数”类型; 它们是C意味着int和unsigned int 。 尽管这些类型是.NET运行时类型系统的基础，但它们并没有得到关键字的祝福。
因此，我们可以拒绝只有“基本”类型获得关键字的论点。 有一个非基本类型有一个关键字，一个基本类型没有得到一个关键字，所以基本类型和获得关键字的类型之间没有一对一的关系。
Tigran认为选择是“历史性的”，这是正确的，但实际上并没有回答这个问题。
Hans Passant正确地指出，明确指定int的大小和范围有助于使语言行为保持一致，即使本机整数大小发生变化，并注意到DateTime已被设计为“面向未来”。 虽然这种分析是正确的，但它并不能解释为什么十进制被设为关键字。 毫无疑问，机器的“原始小数”将来会发生变化。 此外，C＃语言已经注意到虽然double将总是消耗8个字节的存储空间，但是并不要求C＃将双精度处理限制在仅仅64位的精度; 事实上，C＃程序经常以80或更高的精度进行双重算术。
我不认为这些答案能成功解决这个问题。 那么让我们回到这个问题：
许多类型与C＃中的“速记”关键字相关联; 例如，
System.Int32也可以写成int而System.String可以写成string。 为什么没有System.DateTime的简写？
这个问题的答案与“为什么C＃没有实现我喜欢的function？”forms的每个问题的答案相同。 答案是： 我们不需要提供不实现function的理由。 function很昂贵 ，正如Raymond Chen经常指出的那样， 默认情况下未实现 。 保留未实现的未实现function是没有用的。
function建议完全没有道理 ; 在某种意义上，Visual Basic将DateTime视为一种特殊类型，如果我们认为值得做这项工作，C＃也可以。 但并非所有合理的function都得到实施。
存在用于C＃语言的Int32，Int64等的别名，以使语言面向未来。 当每个人的桌面计算机都有256位内核时，仍然要使它相关。 有了整体的折边和咀嚼来真正实现这一点，周围的C＃代码量隐含地假设 int是32位是很普遍的。 但实际上并没有那么难，我把我从CP / M写到MS-DOS到Windows 3.x到Windows NT的代码块移动了很少。
这不是DateTime的问题。 它直到万年才具有前瞻性。 我相信并希望到那时机器能够理解我的意思，而不是我输入的内容:)
除了BCL / .NET团队的其他人之外没有其他人可以给出真正的答案，但我认为这只是历史原因 ，比如char ， float ……和他们的“扩展”类型（如注释中的int – > uint matnioned）有，对于其他人没有。
我可以为其他.NET Framework type类型提出相同的问题，因为我们在.NET中有string简写，但string是引用类型。 所以…
希望我能解释一下。