When I use the "full" timezone name like "America/New_York", how does libc resolve the ambiguity during the extra hour of the transition from daylight saving time to standard time?
Tzdb has the date and time that location starts/reverts DST. It is updated regularly to keep up with regions changing the time zones. It happens frequently than many of us like.
I'm not sure I follow (and this week, timezones and time handling are really important for my job, so I really want to understand)!
If a user provides a time of 11/7/2021 1:50 AM America/New_York, how does the library determine if it's a -5 or -4 offset given that's when daylight savings time ends? I believe that's the ambiguity GP is referring to.
I'm trying to align time across a few systems I work with. One provides a GMT time with an offset (clean and useful), another system reports timezones and local time, and yet another system has no idea when it moves between time zones, but reports time based on a single timezone consistently.
Not dealing with multiple timezones in the past, it reminds me of Tom Scott's video on handling time and timezones, summarized at the end as roughly "Go find someone who built a library for handling times, thank them profusely, use their open source code, give them credit, and never worry about it again."
> If a user provides a time of 11/7/2021 1:50 AM America/New_York, how does the library determine if it's a -5 or -4 offset given that's when daylight savings time ends?
Edit: I originally misunderstood your question. Since (in the future) 2021-11-07 02:00 is when we change to standard time, how does a library know whether to apply a -5 or -4 offset to 01:50?
The library will need to make assumptions about the inputs and it would probably stick with the original offset (one should check the source). For a human-facing interface, it'd be a good idea to raise the issue.
> The mktime() function converts a broken-down time structure, expressed as local time, to calendar time representation. The function ignores the values supplied by the caller in the tm_wday and tm_yday fields. The value specified in the tm_isdst field informs mktime() whether or not daylight saving time (DST) is in effect for the time supplied in the tm structure: a positive value means DST is in effect; zero means that DST is not in effect; and a negative value means that mktime() should (use timezone information and system databases to) attempt to determine whether DST is in effect at the specified time.
So, not specified.
POSIX is no clearer about which choice it will make [1]:
> The mktime() function shall convert the broken-down time, expressed as local time, in the structure pointed to by timeptr, into a time since the Epoch value with the same encoding as that of the values returned by time(). The original values of the tm_wday and tm_yday components of the structure shall be ignored, and the original values of the other components shall not be restricted to the ranges described in <time.h>.
> A positive or 0 value for tm_isdst shall cause mktime() to presume initially that Daylight Savings Time, respectively, is or is not in effect for the specified time. A negative value for tm_isdst shall cause mktime() to attempt to determine whether Daylight Savings Time is in effect for the specified time.
> Local timezone information shall be set as though mktime() called tzset().
> The relationship between the tm structure (defined in the <time.h> header) and the time in seconds since the Epoch is that the result shall be as specified in the expression given in the definition of seconds since the Epoch (see XBD Seconds Since the Epoch) corrected for timezone and any seasonal time adjustments, where the names other than tm_yday in the structure and in the expression correspond, and the tm_yday value used in the expression is the day of the year from 0 to 365 inclusive, calculated from the other tm structure members specified in <time.h> (excluding tm_wday).
> Upon successful completion, the values of the tm_wday and tm_yday components of the structure shall be set appropriately, and the other components shall be set to represent the specified time since the Epoch, but with their values forced to the ranges indicated in the <time.h> entry; the final value of tm_mday shall not be set until tm_mon and tm_year are determined.
... but i think the final paragraph implies that the tm_isdst field in the input time should at least be set to indicate which choice was made!
Java is explicit [2]:
> In most cases, there is only one valid offset for a local date-time. In the case of an overlap, where clocks are set back, there are two valid offsets. This method uses the earlier offset typically corresponding to "summer".