Hi,

looks like I'm running the testsuite against glibc and not newlib (for 
target x86_64-pc-linux-gnu). I'm not even sure whether there's a backend 
for linux.

I'm currently trying to run only the tzset code against the test vectors 
(like Brian Inglis did[1]).

At least it show, that the newlib implementation differs from glibc. 
Maybe the test case is flawed and it should indeed fail.

> 6:20:12 is the timezone string of the previous test case, whose tzset
> call was successful. Looking at the current code, this is expected
> behaviour.

Okay. Looks like the condition[2] fails. The question is, which part of 
it does?

I've appended a patch, which prints all variables when the condition 
fails. Could you please apply the patch and then recompile and re-run 
the tests again?

I've previously noticed something with the sscanf format[3].

> Perhaps TZ should be reset to UTC before the bail out?

I don't think the implementation should fall back to UTC whenever 
parsing failed. It apparently doesn't in glibc. I'm not sure if the 
behavior is specified somewhere.

Maybe resetting it before each test case is a good idea, though. That 
makes it clearer, why the test case failed.

> With that chunk removed, as shown below:
>     {"3:33:33",               IN_SECONDS(3, 33, 33),   NO_TIME},                 // truncates the name (17 + 1)
> I still get:
>   Assertion failed! Expected 1647906533 to equal 1647916532. winter time, timezone = "3:33:33"

My bad; "3:33:33" isn't a valid timezone string. It has to be prefixed 
by a name e.g. "MESZ" or "<+00>", as you tried. That explains why it is 
also failing.


Thanks for your effort so far!


[1]: https://sourceware.org/pipermail/newlib/2022/019529.html
[2]: 
https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/time/tzset_r.c;h=9cb30b188f989f65ec9eb6417f5d74020f8c72e9;hb=HEAD#l57
[3]: https://sourceware.org/pipermail/newlib/2022/019535.html


Cheers
---
🙎🏻‍♂️ jdoubleu