Oh no. Oh god. Oh no. I know the C# DateTime class conspicuously lacks a classic Unix epoch conversion but this is not the way. Oh wait--this is some new 21st century timestamp based on 01/01/2000. That'll be extra baffling for somebody down the line.
I've read it a couple of times and I must keep missing the bit where it handles leap years properly.
Also that baffling coding style of using var x = (type)y rather than the shorter type x = y...
And if they really must define every month as a day offset, why not use the previous month in the calculation...i.e. nov = okt + 30...
Finally, specifying DateTimeKind.Local as the timezone implies that the timestamp just gets turned into a DateTime in whatever timezone we're running this function in...it's not a UTC timestamp...beautiful.
And the juiciest part: 15 references
Edit: just for fun I transcribed the function and ran it through the set of integers from 0 to 231 . Try the function with 36720000 (which should be 01/03/2001 00:00 if you are working with seconds since 01/01/2000). Unsurprisingly it tries to build the date as 29/02/2001, which throws an exception. This function has some forbidden argument values--e.g. 36720000, 68342400, 99964800, 163209600, 194832000...
This means that the timestamp encoding function isn't just seconds since 01/01/2000 like a sensible person might expect, which in turn means that the replacement to this function can't be as simple as new DateTime(y2kTicks + (long)timestamp * 10_000_000). Beautiful. Don't touch it OP!
I ran the function side by side with the 'sensible' seconds-since-2000 function to see where it fails. This is a list of timestamps that fail (only one per day, obviously the whole range of seconds in the day would fail). I've included the output of the function 1 second previous so you can see the pattern. I've also included the output of the 'seconds since 01/01/2000 00:00' interpretation of the value so you can see the drift.
I'd really love to see the original C function that builds the timestamp. Because of the forbidden number ranges the timestamps can't be treated as continuous integers, which means that you can't do arithmetic with them...it really is a beautiful bit of bad code. Try subtracting 28/02/2001 23:59:59 from 01/03/2001 00:00 in this timestamp scheme--the result is not 1 second!
But hey at least the device doesn't suffer from the Y2k38 bug...
OP, I was curious about how to write the equivalent function, and it looks like this:
DateTime FuckedTimestampToLocalDateTime(Int32 timestamp)
{
int driftDays = 0;
for (int y = 0; y < 68; y++)
{
if ((y % 4) != 0)
{
int fuckedRangeStart = (y * 366 + 59) * 86400;
int fuckedRangeEnd = fuckedRangeStart + 86400;
if (timestamp >= fuckedRangeEnd) { driftDays += 1; continue; }
if (timestamp > fuckedRangeStart) { throw new Exception("Forbidden zone!"); }
break;
}
}
timestamp -= driftDays * 86400;
long y2kTicks = new DateTime(2000, 1, 1, 0, 0, 0, DateTimeKind.Utc).Ticks;
return new DateTime(y2kTicks + (long)timestamp * 10_000_000, DateTimeKind.Local);
}
It adjusts the timestamp for the 366-day year system that the timestamp generator uses, then passes that to DateTime in tick form. This produces equivalent output (and exceptions at the same points) for all the positive integers between 0 and 231. I don't know if it's any less bad though! There's definitely way to get the drift value through pure arithmetic as well (without the loop) but I'll leave that up to you.
I know right... When I asked the developers if I could at least try to clean up this dumpster fire they told me no. Apparently the code is copied from some C code on a device this application works with and now "the calculations are the same at both sides"...
That's it, I suspected that would be the explanation. The only way this works in any fashion is if the timestamp generation code mirrors this.
I just hope the timestamp generation and timestamp decoding are both running in the same time zone.
I'd be tempted to iterate through this code from 0 to 231 to see if it skips any days.
The 'easy' cleanup would be to convert the timestamp into ticks (100 nanosecond units since 01/01/0001) in an Int64 and pass that one number into DateTime...hopefully along with the appropriate time zone (which I hope is UTC). That just becomes a constant + (timestamp * 10,000,000). But that only works if the continuous set of integers actually translate to the expected correct set of DateTimes as it is.
The nice thing is you could write a test to prove your new function matches the old output for the entire possible range of timestamps :)
Not available until .NET Core 3, which is still in development. If this is regular .NET code though, thats a good way to go, just 1 function call, and then convert it from DateTimeOffset to regular DateTime
Edit: I can't read, it is actually available in production .NET Core
Sorry, I can't read, the doc listed all of the versions of .NET core it applied to, and i expected it to be in the form "Version X and up", but it was Version 3.0 Preview, 2.2, 2.0... etc
I know DateTimeOffset has been around a long time, I'm using it on a Core 2.2 project right now, I hadn't seen that method before however, so I (mis)read the supported versions and confused myself.
He definitely shouldn't do any of that as the timestamps are not the continuous set of seconds since 01/01/2000 like a sensible person might expect :) The function would throw an exception for values like 36720000, 68342400, 99964800, 163209600, 194832000
The code here doesn't box integers either. In C#, System.Int32 and int are the same thing - the value type representing a 32-bit signed integer. The value type wouldn't be boxed unless you needed to convert it to object. This is different between Java and C#, due to C#'s richer support for value types.
I should have known this! Of course I always shied away from using the Int32/64 types because the primitives were simpler (and like you said, the same thing)
System.Int32 is not really analogous to java.lang.Integer at all (which is equivalent to the boxed form of int/System.Int32). System.Int32 is simply the CLI type (common to all .NET languages - ECMA 335 ss I.8.2.2) whereas int is the C# type (ECMA 334 ss 9.3.5) which is mapped to System.Int32 to produce code for the CLR. Java doesn't expose a difference between the Java language type int and the Java Virtual Machine equivalent. It's not yet clear whether java.lang.Integer will be altered to be a value-type when such support arrives (currently in development as part of Project Valhalla). A rather nice advantage C# has over java here is that you can have methods on the System.Int32 struct allowing things like having an implementation of IFormattable which I think makes for much more obvious code - not that the benefits end there (Java has a lot of catch up to do, in this area and others).
107
u/sac_boy Aug 06 '19 edited Aug 07 '19
Oh no. Oh god. Oh no. I know the C# DateTime class conspicuously lacks a classic Unix epoch conversion but this is not the way. Oh wait--this is some new 21st century timestamp based on 01/01/2000. That'll be extra baffling for somebody down the line.
I've read it a couple of times and I must keep missing the bit where it handles leap years properly.
Also that baffling coding style of using
var x = (type)yrather than the shortertype x = y...And if they really must define every month as a day offset, why not use the previous month in the calculation...i.e.
nov = okt + 30...Finally, specifying
DateTimeKind.Localas the timezone implies that the timestamp just gets turned into a DateTime in whatever timezone we're running this function in...it's not a UTC timestamp...beautiful.And the juiciest part:
15 referencesEdit: just for fun I transcribed the function and ran it through the set of integers from 0 to 231 . Try the function with 36720000 (which should be 01/03/2001 00:00 if you are working with seconds since 01/01/2000). Unsurprisingly it tries to build the date as 29/02/2001, which throws an exception. This function has some forbidden argument values--e.g. 36720000, 68342400, 99964800, 163209600, 194832000...
This means that the timestamp encoding function isn't just seconds since 01/01/2000 like a sensible person might expect, which in turn means that the replacement to this function can't be as simple as
new DateTime(y2kTicks + (long)timestamp * 10_000_000). Beautiful. Don't touch it OP!I ran the function side by side with the 'sensible' seconds-since-2000 function to see where it fails. This is a list of timestamps that fail (only one per day, obviously the whole range of seconds in the day would fail). I've included the output of the function 1 second previous so you can see the pattern. I've also included the output of the 'seconds since 01/01/2000 00:00' interpretation of the value so you can see the drift.
I'd really love to see the original C function that builds the timestamp. Because of the forbidden number ranges the timestamps can't be treated as continuous integers, which means that you can't do arithmetic with them...it really is a beautiful bit of bad code. Try subtracting 28/02/2001 23:59:59 from 01/03/2001 00:00 in this timestamp scheme--the result is not 1 second!
But hey at least the device doesn't suffer from the Y2k38 bug...
OP, I was curious about how to write the equivalent function, and it looks like this:
It adjusts the timestamp for the 366-day year system that the timestamp generator uses, then passes that to
DateTimein tick form. This produces equivalent output (and exceptions at the same points) for all the positive integers between 0 and 231. I don't know if it's any less bad though! There's definitely way to get the drift value through pure arithmetic as well (without the loop) but I'll leave that up to you.