[libcxx-commits] [PATCH] D144739: [libc++][chrono] Add sys_time formatter.

[Mark de Wever via Phabricator via libcxx-commits]

Mordante added a comment.

In D144739#4261996 <https://reviews.llvm.org/D144739#4261996>, @bjope wrote:

> In D144739#4261870 <https://reviews.llvm.org/D144739#4261870>, @Mordante wrote:
>
>> In D144739#4260494 <https://reviews.llvm.org/D144739#4260494>, @bjope wrote:
>>
>>> Started to see failures as shown below, downstream, after merging this patch.
>>>
>>> So it seems like in my environment it says "GMT" instead of "UTC" (or perhaps the other way around).
>>> Not sure exactly what might cause that and how to debug this problem. Any clues to what might cause this or what to look for?
>>>
>>>   # command stderr:
>>>   
>>>   Format string   {:L%%c='%c'%t%%Ec='%Ec'%n}
>>>   Expected output %c='jeu. 01 janv. 1970 00:00:00 GMT'	%Ec='jeu. 01 janv. 1970 00:00:00 GMT'
>>>   
>>>   Actual output   %c='jeu. 01 janv. 1970 00:00:00 UTC'	%Ec='jeu. 01 janv. 1970 00:00:00 UTC'
>>>   
>>>   t.tmp.exe: /repo/llvm-project/libcxx/test/std/time/time.syn/formatter_tests.h :41 : void check(std::basic_string_view<CharT>, test_format_string<CharT, Args...>, Args &&...) [CharT = char, Args = <std::chrono::time_point<std::chrono::system_clock, std::chrono::duration<long long>>>]:  l'assertion « out == expected » a échoué.
>>>   
>>>   error: command failed with exit status: 250
>>>   
>>>   --
>>>   
>>>   ********************
>>>   Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. 
>>>   
>>>   1 warning(s) in tests
>>>   ********************
>>>   Failed Tests (1):
>>>     llvm-libc++-shared.cfg.in :: std/time/time.syn/formatter.sys_time.pass.cpp
>>
>> These test highly depend on the platform specific libc's output. Which platform and libc are you using?
>> (Unfortunately it seems several platforms have other ideas how something is a specific locale should be.)
>>
>> If you look at the failed test in this patch you already see quite some `#ifdef`s. The easiest solution for me would be to get a patch for your specific platform.
>
> Right. I've noticed :-)
>
> I'm on linux, RHEL7.9, targeting x86_64-unknown-linux-gnu. But not sure exactly what to look for. I just tried using a similar cmd line and adding "-dM", and it looks like I've got GLIBC 2.17. But no idea if this problem is specific to GLIBC or something else, so I wouldn't dare putting up a patch that expect UTC specifically for GLIBC 2.17.
>
> For now I've just disabled the test case, so it is not causing me that much trouble. But I guess there might be others out there with similar problems.

According to https://sourceware.org/glibc/wiki/Glibc%20Timeline GLIBC 2.17 is over 10 years old. We don't have a fixed policy on which versions of GLIBC we support. Since most users don't run our tests and you have solved it locally I prefer to keep the code as is. If there are more bug reports with newer GLIBC versions I can look at another `#ifdef`.

I'm actually surprised there are not more parts of the C library, we depend on, missing with such an old GLIBC version.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144739/new/

https://reviews.llvm.org/D144739