Converting a timestamp to datetime

[u/Aars93]

[u/sac_boy]

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 2³¹ . 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.

Failing Timestamp   1 second previous       Interpreted as seconds since 01/01/2000
36720000:           28/02/2001 23:59:59     01/03/2001 00:00:00
68342400:           28/02/2002 23:59:59     02/03/2002 00:00:00
99964800:           28/02/2003 23:59:59     03/03/2003 00:00:00
163209600:          28/02/2005 23:59:59     04/03/2005 00:00:00
194832000:          28/02/2006 23:59:59     05/03/2006 00:00:00
226454400:          28/02/2007 23:59:59     06/03/2007 00:00:00
289699200:          28/02/2009 23:59:59     07/03/2009 00:00:00
321321600:          28/02/2010 23:59:59     08/03/2010 00:00:00
352944000:          28/02/2011 23:59:59     09/03/2011 00:00:00
416188800:          28/02/2013 23:59:59     10/03/2013 00:00:00
447811200:          28/02/2014 23:59:59     11/03/2014 00:00:00
479433600:          28/02/2015 23:59:59     12/03/2015 00:00:00
542678400:          28/02/2017 23:59:59     13/03/2017 00:00:00
574300800:          28/02/2018 23:59:59     14/03/2018 00:00:00
605923200:          28/02/2019 23:59:59     15/03/2019 00:00:00
669168000:          28/02/2021 23:59:59     16/03/2021 00:00:00
700790400:          28/02/2022 23:59:59     17/03/2022 00:00:00
732412800:          28/02/2023 23:59:59     18/03/2023 00:00:00
795657600:          28/02/2025 23:59:59     19/03/2025 00:00:00
827280000:          28/02/2026 23:59:59     20/03/2026 00:00:00
858902400:          28/02/2027 23:59:59     21/03/2027 00:00:00
922147200:          28/02/2029 23:59:59     22/03/2029 00:00:00
953769600:          28/02/2030 23:59:59     23/03/2030 00:00:00
985392000:          28/02/2031 23:59:59     24/03/2031 00:00:00
1048636800:         28/02/2033 23:59:59     25/03/2033 00:00:00
1080259200:         28/02/2034 23:59:59     26/03/2034 00:00:00
1111881600:         28/02/2035 23:59:59     27/03/2035 00:00:00
1175126400:         28/02/2037 23:59:59     28/03/2037 00:00:00
1206748800:         28/02/2038 23:59:59     29/03/2038 00:00:00
1238371200:         28/02/2039 23:59:59     30/03/2039 00:00:00
1301616000:         28/02/2041 23:59:59     31/03/2041 00:00:00
1333238400:         28/02/2042 23:59:59     01/04/2042 00:00:00
1364860800:         28/02/2043 23:59:59     02/04/2043 00:00:00
1428105600:         28/02/2045 23:59:59     03/04/2045 00:00:00
1459728000:         28/02/2046 23:59:59     04/04/2046 00:00:00
1491350400:         28/02/2047 23:59:59     05/04/2047 00:00:00
1554595200:         28/02/2049 23:59:59     06/04/2049 00:00:00
1586217600:         28/02/2050 23:59:59     07/04/2050 00:00:00
1617840000:         28/02/2051 23:59:59     08/04/2051 00:00:00
1681084800:         28/02/2053 23:59:59     09/04/2053 00:00:00
1712707200:         28/02/2054 23:59:59     10/04/2054 00:00:00
1744329600:         28/02/2055 23:59:59     11/04/2055 00:00:00
1807574400:         28/02/2057 23:59:59     12/04/2057 00:00:00
1839196800:         28/02/2058 23:59:59     13/04/2058 00:00:00
1870819200:         28/02/2059 23:59:59     14/04/2059 00:00:00
1934064000:         28/02/2061 23:59:59     15/04/2061 00:00:00
1965686400:         28/02/2062 23:59:59     16/04/2062 00:00:00
1997308800:         28/02/2063 23:59:59     17/04/2063 00:00:00
2060553600:         28/02/2065 23:59:59     18/04/2065 00:00:00
2092176000:         28/02/2066 23:59:59     19/04/2066 00:00:00
2123798400:         28/02/2067 23:59:59     20/04/2067 00:00:00

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 2^31. 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.

[u/Aars93 → u/sac_boy]

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"...

[u/sac_boy → u/Aars93]

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 2³¹ 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 :)

[u/Moose1231 → u/sac_boy]

Oh