Tracking Issue for Extensions to Chrono

[mnatsuhara]

📄 Primary Sources

• Feature Issue: P0355R7 <chrono> Calendars And Time Zones #12 <chrono> Calendars And Time Zones
• WG21-P0355 <chrono> Calendars And Time Zones
• WG21-P1466 Miscellaneous Minor Fixes For <chrono>
• WG21-P1650 Printing std::chrono::days With Suffix "d"
• WG21-P1981 Renaming leap To leap_second
• WG21-P1982 Renaming link To time_zone_link

🚧 Status

• The primary resource for status updates is the Extensions to <chrono> project
• Outside of a few remaining bugs (for which we have filed issues), we are feature-complete! 🎉

🗺️ Roadmap

• There are several PRs who have contributed work toward completion of this feature! See the <chrono> project for a complete list.
• The time-zone related work in <chrono> had many moving parts, many of which depended on each other. The rough dependency graph below helped guide the order of implementation for the various pieces (e.g., sys_info, local_info ➡️ zoned_time means that sys_info, local_info are required for zoned_time).
  • The different colored outlines suggest what pieces might makes sense to implement in a single PR (note that these are suggestions, not requirements).

• Note that some aspects of [time.zone] are best-implemented for more recent OSes (specifically, utilization of the icu.dll for time zone information, leap second registry calls, etc.). To declare feature completion, we are satisfied with merging implementations for these more recent OSes. We've filed <chrono>: Implement fallback mechanism for chrono's [time.zone] #1911 to track this work.

⌨️ Blogpost / Documentation Notes

• The ICU DLL we are using for time-zone-related data is only available in more recent Windows OSes (19H1 and after). We plan to come back and implement a fallback for older OSes, but this will likely not be included in the initial implementation.
• If we stick with the file_clock::to_utc and file_clock::from_utc implementations (instead of the to_sys, from_sys option instead), we should include the note that pre-2017 leap seconds will not be representable through file_time (as FILETIME only became leap-second-aware as of Server 2019 and Windows 10 October update).
• The ICU API classifies time zones and alternate names for time zones ("canonical" and "non-canonical"), and these categorizations differ from what the IANA database considers to be "standard" and "alternate" names (alternate names used for time_zone_link).
  • Unfortunately, there is no easy mapping between these two classification systems. Without attempting to list and maintain a complete list of all IANA-"standard" time zones and IANA-"alternate" names, there is no way to cleanly create an identical mapping.
  • Instead, we will consider all of the ICU time zones (canonical and non-canonical) to be time_zones, and have no time_zone_links. This means that we will supply a superset of the IANA standard and alternate time zones as time_zones, with a few exceptions:
    • The "America/Nuuk" time zone does not appear in the ICU database, but we expect it is because it is a very recent name change from "America/Godthab" in April 2020 (and "America/Godthab" does appear in the ICU database).
    • There are a few somewhat abnormal time zones in the IANA database that do not appear in the ICU database (such as Eastern War Time EWT) - we will report these missing time zones as bugs to ICU, if they are still not found in more recent versions.
• sys_info contains begin and end members whose intent is described here: [time.zone.info.sys]/3 - their range is not specified, but we plan to enforce that they are clamped at chrono::year::min() and chrono::year::max().
• Much of our [time.format] implementation relies on strftime for handling of many of the specifiers. Currently, strftime does not yet support some of the modifiers (e.g., O and E) that it should, and support for this is not expected anytime soon (due dependency on Win32 locale APIs). We do not attempt to handle these cases manually, but our implementation should be conformant in this respect ifstrftime's implementation also becomes conformant.
• I built a table of the "chronat" types and which format specifiers were valid for them, as this information needed to be inferred from the Standard: chronat_table.pdf

[kasperk81]

once strftime's implementation is also conformant.

Is this something being tracked in the ucrt team's backlog?

[StephanTLavavej]

@amyw-msft (who works on the UCRT) has an internal spreadsheet tracking the status of "Additional strftime conversion specifiers", but I don't know if there are active plans to implement them.

[amyw-msft]

There are not plans to implement strftime %O and %E. Our implementation is backed by the Win32 Locale APIs which don't really have a concept of a single "alternate calendar" or "alternate numeric system".

[barcharcraz]

we could just implement O and E as identical to o and e for all locales, I think that would conform.

[kasperk81]

@barcharcraz, can you think of a test which shows in what way it doesn't conform today? I started with:

// file:           strftime_test.c
// compile cmd:    cl.exe strftime_test.c
// (Compiler Version 19.28.29914)

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

int main (void)
{
  struct tm tm =
  {
    .tm_year = 102,
    .tm_mon = 2,
    .tm_mday = 1
  };

  char buf[100];
  if (strftime (buf, sizeof (buf), "Ec = %Ec\nOe = %Oe", &tm) == 0)
  {
    puts ("initial strftime failed");
    exit (1);
  }

  printf ("%s\n", buf);
  return 0;
}

// output:
//
//   Ec = Sun Mar  1 00:00:00 2002
//   Oe =  1

[mnatsuhara]

If strftime's handling of modifiers O and E are just to fallback to the unmodified versions of the format specifiers, then maybe we have no work to do here!

[kasperk81]

Yes, it seems like compiler just falls back or in other words, it ignores %E and %O.

From the conformance table https://docs.microsoft.com/en-us/cpp/overview/visual-cpp-language-conformance?view=msvc-160, I think we can update this line:

The Universal CRT implements the parts of the C11 Standard Library that are required by C++17, except for C99 strftime() E/O alternative conversion specifiers, and C11 aligned_alloc(). The latter is unlikely to be implemented because the Windows operating system doesn't support aligned allocations.

to reflect that strftime() E/O options are (also) unlikely to be implemented?

[mnatsuhara]

I can modify the issue content to reflect that we're not "actively waiting" for %O and %E support from strftime, but instead this is not something that we expect to be supported anytime soon given the limitations of the Win32 locale APIs. Since this behavior is consistent with the behavior in strftime, I think this should be fine.