3 ms·

The first thing I did when I read this article is lookup C#'s (.Net's) DateTime.MaxValue constant. It's 23:59:59.9999999 UTC, December 31, 9999. https://docs.m

The first thing I did when I read this article is lookup C#'s (.Net's) DateTime.MaxValue constant. It's 23:59:59.9999999 UTC, December 31, 9999. https://docs.microsoft.com/en-us/dotnet/api/system.datetime.maxvalue?view=net-6.0 https://docs.microsoft.com/en-us/dotnet/api/system.datetime.... I was honestly surprised, because normally limits for binary digits don't coincide with decimal limits. DateTime.MaxValue is 0x2BCA2875F4373FFF. Looking in the source for DateTime, internally it's a 64-bit unsigned integer. The lower 62 bits are used for a date, and the upper 2 are used to flag local/utc/dst. The 62 bits technically allow for an extra ~81 days into the year 10,000. (Makes me wonder if, in 7950 years or so, someone's going to recompile a bunch of C# code to use an updated version of DateTime.)

ralferoo 5y ago
> DateTime.MaxValue is 0x2BCA2875F4373FFF. > The 62 bits technically allow for an extra ~81 days into the year 10,000. Just eyeballing it from starting 0x2B... which is about 2/3 of 0x3F... which would be the maximum value of 62 bits, I'm pretty sure you've miscalculated! Looking at the docs, 0x0 represents 1/1/1 AD, so that means the 62 bits can suffice for almost 5000 years beyond DateTime.MaxValue. So, people's code will still work for a little while afterwards, even if they aren't printed correctly! But anyway, it's all kind of a moot point. 8000 years ago is about the limit of known human civilisation, so it's unlikely that any of the technology we create today will still be considered important the same distance into the future. Not only has every country on earth gone through at least one entire calendar reform in the last 8000 years, and many countries that use the concept of DST feel the need to change the dates when it occurs every few years, the chance of this being an issue for anyone is approximately 0.
- DaiPlusPlus 5y ago
  > so it's unlikely that any of the technology we create today will still be considered important the same distance into the future. Let's say the wheel, or reproductible fire, or written language, probably happened around 8,000 years ago - I'd say that's pretty danged important and should be memorialized.
- mucle6 5y ago
  !RemindMe 8000 years \s
- gwbas1c 5y ago
  Yeah, it was a throwaway Linqpad script on my work computer, so I can't go back and see what screwed up. I rewrote it on my Mac, which doesn't have Linqpad: using System; namespace DateTime_Headroom { class Program { static void Main(string[] args) { Console.WriteLine( "DateTime.MaxValue in hex: 0x" + DateTime.MaxValue.Ticks.ToString("X")); const ulong DATETIME_RESERVED_BITS = 0xC000000000000000; Console.WriteLine( "DateTime reserved bits in hex: 0x" + DATETIME_RESERVED_BITS.ToString("X")); const long DATETIME_TICKS_BITS = (long)~DATETIME_RESERVED_BITS; Console.WriteLine( "DateTime ticks bits in hex: 0x" + DATETIME_TICKS_BITS.ToString("X")); var extraTicks = DATETIME_TICKS_BITS - DateTime.MaxValue.Ticks; Console.WriteLine( "DateTime extra ticks in hex: 0x" + extraTicks.ToString("X")); Console.WriteLine($"DateTime extra days: {extraTicks / TimeSpan.TicksPerDay}"); } } } ---- DateTime.MaxValue in hex: 0x2BCA2875F4373FFF DateTime reserved bits in hex: 0xC000000000000000 DateTime ticks bits in hex: 0x3FFFFFFFFFFFFFFF DateTime extra ticks in hex: 0x1435D78A0BC8C000 DateTime extra days: 1685540 Edit: Sorry about the formatting. Also, kinda makes me wonder about the tradeoffs. I suspect that the performance advantage of 64-bit math over "bigint" math is much more useful than the risk of recompiling a program in 10,000 years to use a 128-bit date.
  - kingcharles 5y ago
    Username gwbas1c. Programs in C#. How about some love for VB.NET around here, huh?
    - gwbas1c 5y ago
      I stopped at Visual Basic 6. I inherited a little bit of VB.Net back when C# was new and I honestly don't get the point of the language. A lot of the simplifications that were in classic Visual Basic just aren't in the .Net version. It was kind of useful if you really needed weak typing, but that's really a niche usage that duck typing in C# now handles.
      - kingcharles 5y ago
- kingcharles 5y ago
  Allows for 8000 future years, but does not allow for negative year. Although once you get into negative years I guess you'd need a range of almost 14 billion just for the year value.

ralferoo 5y ago

> DateTime.MaxValue is 0x2BCA2875F4373FFF. > The 62 bits technically allow for an extra ~81 days into the year 10,000. Just eyeballing it from starting 0x2B... which is about 2/3 of 0x3F... which would be the maximum value of 62 bits, I'm pretty sure you've miscalculated! Looking at the docs, 0x0 represents 1/1/1 AD, so that means the 62 bits can suffice for almost 5000 years beyond DateTime.MaxValue. So, people's code will still work for a little while afterwards, even if they aren't printed correctly! But anyway, it's all kind of a moot point. 8000 years ago is about the limit of known human civilisation, so it's unlikely that any of the technology we create today will still be considered important the same distance into the future. Not only has every country on earth gone through at least one entire calendar reform in the last 8000 years, and many countries that use the concept of DST feel the need to change the dates when it occurs every few years, the chance of this being an issue for anyone is approximately 0.

DaiPlusPlus 5y ago
> so it's unlikely that any of the technology we create today will still be considered important the same distance into the future. Let's say the wheel, or reproductible fire, or written language, probably happened around 8,000 years ago - I'd say that's pretty danged important and should be memorialized.
mucle6 5y ago
!RemindMe 8000 years \s
gwbas1c 5y ago
Yeah, it was a throwaway Linqpad script on my work computer, so I can't go back and see what screwed up. I rewrote it on my Mac, which doesn't have Linqpad: using System; namespace DateTime_Headroom { class Program { static void Main(string[] args) { Console.WriteLine( "DateTime.MaxValue in hex: 0x" + DateTime.MaxValue.Ticks.ToString("X")); const ulong DATETIME_RESERVED_BITS = 0xC000000000000000; Console.WriteLine( "DateTime reserved bits in hex: 0x" + DATETIME_RESERVED_BITS.ToString("X")); const long DATETIME_TICKS_BITS = (long)~DATETIME_RESERVED_BITS; Console.WriteLine( "DateTime ticks bits in hex: 0x" + DATETIME_TICKS_BITS.ToString("X")); var extraTicks = DATETIME_TICKS_BITS - DateTime.MaxValue.Ticks; Console.WriteLine( "DateTime extra ticks in hex: 0x" + extraTicks.ToString("X")); Console.WriteLine($"DateTime extra days: {extraTicks / TimeSpan.TicksPerDay}"); } } } ---- DateTime.MaxValue in hex: 0x2BCA2875F4373FFF DateTime reserved bits in hex: 0xC000000000000000 DateTime ticks bits in hex: 0x3FFFFFFFFFFFFFFF DateTime extra ticks in hex: 0x1435D78A0BC8C000 DateTime extra days: 1685540 Edit: Sorry about the formatting. Also, kinda makes me wonder about the tradeoffs. I suspect that the performance advantage of 64-bit math over "bigint" math is much more useful than the risk of recompiling a program in 10,000 years to use a 128-bit date.
- kingcharles 5y ago
  Username gwbas1c. Programs in C#. How about some love for VB.NET around here, huh?
  - gwbas1c 5y ago
    I stopped at Visual Basic 6. I inherited a little bit of VB.Net back when C# was new and I honestly don't get the point of the language. A lot of the simplifications that were in classic Visual Basic just aren't in the .Net version. It was kind of useful if you really needed weak typing, but that's really a niche usage that duck typing in C# now handles.
    - kingcharles 5y ago
kingcharles 5y ago
Allows for 8000 future years, but does not allow for negative year. Although once you get into negative years I guess you'd need a range of almost 14 billion just for the year value.