On Tue, Nov 01, 2022 at 05:20:17 +0700, Robert Elz wrote: > How are you proposing that a portable implementation of strftime() > done today, before the next posix standard is released (maybe next > year, but perhaps not until 2024) would achieve what you're requesting?
I think this is the point of confusion. It's not useful to pretend that struct tm and strftime are the proverbial spherical horses in vacuum and argue for "a portable implementation" of strftime, and then from that argument infer properties for all potential implementations of strftime including those that are privy to the implementation details of its own struct tm - which all "real" strftime implementations do. The problematic bit in your argument is specifically that inference step. POSIX doesn't specify the private parts of struct tm. Yes, public parts of struct tm are not enough to construct tm that is another timezone, but the implementation provides a group of functions that operate on its own private tm that usually does have that information. What initially surprised me, and what I think dh@ is also pointing out, is that %s behaves as if it is indeed "a portable implementation" that doesn't have access to the full tm, including private tz-related parts. I think we both tried to convey that point of view in various ways, apparently without much success. > How do you tell what produced a struct tm? Magic? In other words, class tm doesn't have a public constructor that provides a way to specify TZ info. There are other factory methods that allow one to obtain an instance of tm that has the TZ info (in its private parts). ... But I don't have time or energy to elaborate this argument further because you seem to disagree with the basic premise of it - that for a class method (strftime) to be aware and to use the private data of the class (struct tm as fully defined by the implementation, not just the public "at least the memebers tm_foo, tm_bar" as specified in the standard) is actually a reasonable thing to do. -uwe
