Date: Mon, 11 Dec 2017 17:25:59 -0500 From: scs@eskimo.com (Steve Summit) Message-ID: <2017Dec11.1725.scs.0004@quinine.local> | But with all of that said, I suppose that a program that wanted | to fail less quietly on misinstalled or misconfigured tz data | could, instead of calling this new tz_set_warn_func() first, call | a hypothetical new tzset_with_error(&errorinfo) first, This would be one way, as all the errors/whatever you seem to be interested in are related to tzset and nothing really related to issues after tzset has succeeded (when it succeeds) properly. Alternatively, simply add some error/status info into the internal zone structure, and then add a function to extract status (much like ferror() does for stdio - though perhaps with a little more info available). All in all the second seems like a more useful addition to me, if anything really needs changing at all (the alternative is simply to create a tzverify program, which would do what tzset does, but in a user visible way, so when things are not behaving as they should, the user can just run that program and see exactly what is happening - when everything is correctly configured, none of this extra is needed, it is just extra baggage for most programs, most of the time.) kre