3 ms·
> 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...
by 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 agoYeah, 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 agoUsername gwbas1c. Programs in C#. How about some love for VB.NET around here, huh?
- gwbas1c 5y agoI 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 agoI was a C/x86 developer who switched to VB for an ASP job. Then I became a VB.NET devotee. I kept up with C# the whole time because 99% of sample code was in C# and I needed to understand it. I actually still believe VB.NET is the better language, I think it reads a lot easier and is therefore less susceptible to errors. I've given up though and switched to C# just because the support is there.
- kingcharles 5y agoAllows 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.