C# 诺代与古代

我正在研究维基百科上的一些价值观，这些价值观在某些情况下是百万年前的（比如月亮的形成，维基数据报告称其正在形成：“-4527000000-01-01T00:00:00Z”。在另一种情况下，我只是在看公元前10000年的年份，等等，仍然用“-10000-01-01T00:00:00Z”来表示

据我所知，测试NodaTime和阅读文档，这些古老的年份是不受支持的（或者我忽略了一些东西）。例如，这失败了：

OffsetDateTime defaultValue = new OffsetDateTime(new LocalDateTime(77, 1, 1, 0, 0), Offset.Zero);
var pattern = OffsetDateTimePattern.Create("yyyy-MM-ddTHH:mm:ss'Z'", CultureInfo.InvariantCulture, defaultValue);
string P = "-1000-01-25T20:34:25Z";
var result = pattern.Parse(P);

NodaTime.Text.UnparsableValueException: The value string includes a negative value where only a non-negative one is allowed. Value being parsed: '^-1000-01-25T20:34:25Z'. (^ indicates error position.)
   at NodaTime.Text.ParseResult`1.GetValueOrThrow() in C:\Users\jon\Test\Projects\nodatime\build\releasebuild\src\NodaTime\Text\ParseResult.cs:line 81
   at TryNodaTime.Program.Main(String[] args

使用sing这个字符串效果很好，顺便说一句：string p=“1000-01-25T20:34:25Z”

我希望我只是忽略了一些明显的事情，比如处理非常大的旧日期/年份。其他例子包括旧城，顺便说一句，它们的确切日期早在0年之前

如能就如何处理这些问题提供指导，将不胜感激

编辑：找到了这个示例，它要求我首先手动检测年份，如果年份为负值，则使用LocalDate，但是，它不能解决更大的问题，因为它在-9999以下失败：

LocalDate BCDATE = new LocalDate(Era.BeforeCommon, -15000, 10, 1);
Console.WriteLine($"BC: {BCDATE}");

---

野田佳彦时代不支持古老或遥远的未来价值观

支持的值范围为

野田佳彦的时间只能代表有限范围内的数值。这是出于务实的原因：尽管从对大爆炸的某些估计到某些预期的“时间终结”，我们可以尝试对每一个瞬间进行建模这将给99.99%的程序员带来巨大的经验损失，他们只需要在一个合理的现代（但不是遥远的未来）时代处理日期和时间

Noda Time 1.x版本支持的年份介于-27000和+32000（公历）之间，但在极端情况下存在重大问题。Noda Time 2.0的范围较小，行为定义更明确

此外，所有日历都被限制为四位数格式，即使在纪年表示法中也是如此，这避免了必须解析五位数年份。这将导致公历从公元前9999年到公元前9999年（含）或从“绝对”年份的-9998年到9999年。其他日历的范围由此和自然限制确定（比如说不是催眠的）

恐怕我认为在这个用例中最好不要使用野田佳彦时间，而不要试图解决它——除非你可以有效地逐字报告遥远的日期，并且不做其他工作

---

对此很抱歉-这是一种尝试支持所有用例会损害更常见用例的情况：（

我建议您编写自己的AncientTime结构。在.NET日期时间（和时间跨度）之后对其建模）例如，如果你关心几百万年，你可能不关心时区，你可能不需要像DateTime那样精确。是的，我很确定你不需要超过1秒的精度（顺便说一下，45亿年大约是142000000000000000秒）（大约1.4乘以10到17，如果我的粗略计算正确的话）。你应该能够将大约+/-292000000000年放入一个有符号的64位整数中。当然，时间计算是一件痛苦的事情——例如，在1600年代之前，年长的计算是不同的（没有零年！）。你需要决定你真正想做什么。你是对的，FlyDog，我绝对不需要额外的精确性，基本上只是我追溯那么远的一年。我只是希望NodaTime可以“支持”任何一年，无论是4500万年前还是1971年。如果我选择的库有一种“处理它”的方法，那就更容易了。当然，很可能我必须自己写，我有点期待在这一点上，但也希望如此。如果NodaTime只支持古代的日期（甚至月或年）（放弃所有其他内容），我完全可以，只要我能使用图书馆而不用担心实际的数字。例如，如果它只是忽略了小于一天的任何事情，当一年<-9999时，这将是一个很长的过程…在这里大声思考..我只使用了图书馆大约3个小时..如果你在数百万年中工作，那么月，天，小时等，我会消失不重要。你也可以用

long

或

biginger

来表示你的年份。但是如果你确实需要表示年份的一部分，那么

BigRational

是一个非常棒的选择。对于史前时期，或者接近史前时期，以及遥远的未来，一天之间的差异由一个太阳定义加上一次日落，一天被定义为86400个原子秒，开始成为一个严重的问题。由于Nodatime无法表示这种区别，这些限制可能是合适的。@GerardAshton:事实上，我希望所有类型的“小生境”功能方面，例如，仅相对于其他日期定义的日期，或具有一定程度的模糊性等。感谢Jon，尽管我错过了那条评论，但我还是这么认为。我正在尝试编写一些相当实用的代码，这些代码只适用于我输入的任何内容，因此我将用其他一些代码来封装NodeTime特殊情况。我通常会合并来自数千个API的输入，并尝试尽可能地使其自动化，包括这些奇怪的古老日期。我仍然试图将我的头脑集中在NodaTime上：）。