Guy Harris via tz wrote in <[email protected]>: |> On Jul 20, 2026, at 7:57 PM, Paul Gilmartin via tz <[email protected]> wrote: |> On 7/20/26 16:20, Steffen Nurpmeso wrote: |>> Paul Eggert via tz wrote in |>> ... |>>|tzcode provides a way: if tzalloc("ABC") returns a null pointer and |>>|errno has a value other than ENOMEM, then "ABC" is invalid. So if you're |>>|on platforms like NetBSD that have tzalloc, you have a way. Or you can |>>|copy tzcode and use its tzalloc. |>> |> This appears to be a thread-safe replacement |> for localtime(). I need to RTFM more. | |localtime_r() already serves as a thread-safe replacement for localtime() \ |in most cases. | |However: | |> o localtime() should have a time_t argument. | |localtime() does have a time_t argument, and the time argument to localt\ |ime_r() is also a time_t. | |The same applies to the time argument to localtime_rz() (https://man.net\ |bsd.org/localtime_rz.3). | |> I see no such for tzalloc(). | |This is for the case where localtime_r() is *not* sufficient as a thread\ |-safe replacement for localtime()... | |...i.e., the case where different threads want to convert a time_t \ |to local time in some *arbitrary* timezone, with the timezone being \ |thread-specific. Tweaking the TZ environment variable (if possible, \ |e.g. using setenv()) isn't thread-safe. | |> o strftime() needs a struct tm argument. Does tzalloc() generate one? | |No. | |tzalloc(), as Paul Eggert noted, takes a string argument containing \ |a tzid and return s pointer to an object that represents the timezone \ |corresponding to that tzid. It can be used in localtime_rz() calls \ |to convert a time_t value to a struct tm value for the local time that \ |the time_t represents in that timezone, passed to ctime_rz() to convert \ |a time_t value to a string for the local time that the time_t represents \ |in that timezone, and to mltime_z() to convert a struct tm to the time_t \ |that it represents in that timezone. | |tzfree() frees the object in question.
Yes, object. It is not only about thread-safety, it is about getting an object at hand that (i would presume) encapsulates the resource consumption "etc". This is file reading, and parsing, and more. Back and forth you do this today via $TZ environment variable. But with the object interface you create the object, and if it comes back non-NULL that entire resource thing has sailed. You could even restrict path access to no longer be able to reach the IANA TZ data files. You could possibly restrict the number of systemcalls the process is allowed to perform. Granted: this is a black box with things like GNU libc etc. (For example, syslog is horror, OpenBSD has the desire and used to introduce a syslog "syscall", like that allowing syslog but restricting other calls is easy.) But in theory yes, and this interface allows that to happen, design-wise. That POSIX-reported desire mentions Chrony NTP, and if you think about what it does there, i would wonder if you do not scratch your head -- i did. In that path, these $TZ operations, with what they need to do (as above and furthermore), and that over and over again. That is .. sorry .. nothing but sick. If you got educated by Stroustrup (so to say), and you come from an object-based mindset, that interface and way of doing things, you just do not understand. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
