Brian Inglis wrote:
On 2018-01-26 06:54, Steve Summit wrote:
...in many people's minds, the isdst-related portions of the TZ API have already been pretty severely deprecated for at least 10 years (maybe even 20).
Who has been deprecating which parts of the ABI/API where?
I said "In many people's minds", so I concede that to some extent I'm talking here about subjective reality, not objective fact. But it has seemed pretty obvious (and for a very long time) that several pieces of the traditional, SysV, Posix time interface were either useless, or broken, or both. I'll explain what I mean, but I'm reasonably sure this is not just one man's opinion: it is very much along the lines of what (for example) Robert Elz and Guy Harris have been arguing in this thread; it's what Eric Raymond argues at http://www.catb.org/esr/time-programming/, etc. If you're trying to convert back and forth between machine-readable timestamps (i.e. time_t) and human-readable times, in C, these functions are useful: localtime, gmtime, mktime, strftime These functions and global variables are either not useful, or downright broken: ctime, asctime, timezone, tzname This function, though not standard, is so necessary that it ought to be standard, and one shouldn't feel too bad about using it even though it's not: timegm And then there are the struct tm members. Most of them are useful. But tm_isdst is not remotely useful, for reasons which I think have been adequately exposed in this thread (but I can elaborate if necessary). And, finally, the common struct tm extensions, tm_gmtoff and tm_zone, are so necessary that, again, I wouldn't fault anyone (no matter how zealous about writing portable, standards-compliant code) for using them if available. The notions that timezone, tzname, and tm_isdst are not useful, and that functional invocations of localtime, gmtime, and strftime are much more useful, are coupled with a parallel dichotomy between two separate models for how to think about time and time zones at all. Should we represent a time zone simply as a base offset, and a "dst" offset, and a pair of names, and rules for deciding which (two) times during a year to switch to and from the "dst" offset? Or should we use a mapping -- an arbitrarily complex one -- between UTC and local time, with the offset and the name both being multivariate functions of the time being converted? (Again, the evident superiority of one model should be reasonably obvious based on this thread, but there may be more to say in separate messages.)