[libcxx-commits] [libcxx] [libc++][chrono] Adds the sys_info class. (PR #85619)

[David Spickett via libcxx-commits]

DavidSpickett wrote:

The 2.35 output has more entries for many of the zones. Focal:
```
$ zdump --version
zdump (Ubuntu GLIBC 2.31-0ubuntu9.16) 2.31
tzdata/focal-updates,now 2024a-0ubuntu0.20.04.1 all [installed,automatic]
$ zdump -V -c1800,2100 Africa/Addis_Ababa
Africa/Addis_Ababa  Mon May  4 21:24:39 1936 UT = Mon May  4 23:59:59 1936 ADMT isdst=0 gmtoff=9320
Africa/Addis_Ababa  Mon May  4 21:24:40 1936 UT = Tue May  5 00:24:40 1936 EAT isdst=0 gmtoff=10800
```
Jammy:
```
$ zdump --version
zdump (Ubuntu GLIBC 2.35-0ubuntu3.8) 2.35
tzdata/jammy-updates,now 2024a-0ubuntu0.22.04.1 all [installed,automatic]
$ zdump -V -c1800,2100 Africa/Addis_Ababa
Africa/Addis_Ababa  Fri Dec 31 21:25:11 1869 UT = Fri Dec 31 23:59:59 1869 LMT isdst=0 gmtoff=9288
Africa/Addis_Ababa  Fri Dec 31 21:25:12 1869 UT = Sat Jan  1 00:00:32 1870 ADMT isdst=0 gmtoff=9320
Africa/Addis_Ababa  Mon May  4 21:24:39 1936 UT = Mon May  4 23:59:59 1936 ADMT isdst=0 gmtoff=9320
Africa/Addis_Ababa  Mon May  4 21:24:40 1936 UT = Tue May  5 00:24:40 1936 EAT isdst=0 gmtoff=10800
```

According to @zatrazz  this may be because in glibc 2.34, the armhf version of zdump started to be built with 64 bit time_t support.
https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;h=d488874aba371b2bfa1d99fb607eb653fdd19e17;hb=HEAD#l1331
```
* Add support for 64-bit time_t on configurations like x86 where time_t
  is traditionally 32-bit.  Although time_t still defaults to 32-bit on
  these configurations, this default may change in future versions.
  This is enabled with the _TIME_BITS preprocessor macro set to 64 and is
  only supported when LFS (_FILE_OFFSET_BITS=64) is also enabled.  It is
  only enabled for Linux and the full support requires a minimum kernel
  version of 5.1.
```
Quoting them:
```
On glibc 2.35, zdump is built with 64-bit time_t support on armhf (which was added on 2.34). So when you specify a start/end of time with ‘-c1800,2100’ on glibc 2.31 both will be transformed to 32-bit time_t in the range of [-2147483648,2147483647] (the 
full 32 bit range); while on 2.35 you will get proper 64-bit values [-5364662400, 4102444800]

Since ‘Fri Dec 31 21:25:12 1869’ is lower than the 32-bit time range (~1970), the entries won’t be shown

The glibc 2.35 is the expected value I would say
```

They suggest that using a value that will fit into 32 bit time_t is one possibility, but I think the point of the test is to use a very wide range:
```
constexpr std::chrono::year first{1800};
constexpr std::chrono::year last{2100};
```

Presumably no one is ever going to edit the 1869 entries, so I will try writing a ore-test check to make sure zdump works by looking for those entries.

https://github.com/llvm/llvm-project/pull/85619