Usage of `local_offset()` seems to ignore DST changes about ironhide

[coltfred]

@Kijewski The time that the device was created is in UTC and the adjustment made by util::local_offset() should match the offset of the system that ironhide is being run on. I think this is what I would expect to be the case.

Can you provide a clarifying example if you do not agree?

[Kijewski]

util::local_offset() returns the current offset. For me right now that is UTC+1 (CET), before 2022-10-30 it was UTC+2 (CEST). So for any device created on 2022-10-29 the time will be off by an hour, right?

[cjyar]

Playing with this issue a little bit, we ended up in C. This code:

#include <stdio.h>
#include <time.h>

int main()
{
    struct tm *ptr;
    struct tm *ptr_t;

    /* Nov 5, midnight, GMT */
    time_t t = 1667606400;
    ptr = localtime(&t);
    printf("%s", asctime(ptr));

    /* Nov 7, midnight, GMT */
    time_t tt = 1667779200;
    ptr_t = localtime(&tt);
    printf("%s", asctime(ptr_t));
    return 0;
}

produces this output when run on a laptop in MST currently:

Fri Nov  4 18:00:00 2022
Sun Nov  6 17:00:00 2022

[skeet70]

So yes, we should do this. In addition to #83 I think that means using find_local_time_type to get the offset for the created timestamp.

[Kijewski]

You can use tz::DateTime::from_total_nanoseconds() + tzdb::local_tz() to convert a unix timestamp into a timestamp in the correct time zone, and let from_total_nanoseconds() accurately tell if it's DST or not.