Wow. Thanks for all that detail, Guy. For anyone at risk of drowning in it, though, the simpler answer (as I think someone else already pointed out) is that the second argument to gettimeofday wasn't sufficient and wasn't relevant to most application code anyway. The vast majority of application programs just want to convert UTC to local time, or local back to UTC. They don't really care precisely where the C localtime() function gets its timezone data from. Putting that data into an environment variable (as SysV and Posix did) or into a database keyed by an environment variable (as the ado tzdb does) offered huge advantages, and moreover the mechanism was more or less invisible to most application code. So abandoning gettimeofday's second argument was easy, almost natural. But I'm not sure that's the right question to ask. The more relevant question for this thread, I think, is "Why has the C/Unix world mostly abandoned the tz_isdst field of struct tm?" And the answer to that question is that tm_isdst isn't usually necessary or sufficient, either. On output from localtime(), anyway, tm_isdst doesn't tell you anything you need to know. What you may be more interested in is a name or abbreviation for the local time zone, or the time delta between the local time and UTC. tm_isdst is of no use (at least, not by itself) in answering those questions; what you really want is the tm_zone and tm_gmtoff fields (which are, sadly, not official, but that's another story). So the analogous question for me is, "What are Java programs using isDaylightSavings for? What problems would it cause them if isDaylightSavings's output changed, or if it disappeared? Would some other differently-defined function serve the needs of those programs better?" I don't know much about Java (and nothing about its standardization process), so I take Stephen Colebourne at his word when he says that isDaylightSavings is not going to change for the foreseeable future. But I do still wonder what programs are using it for. * If they're using it as part of their own homebrew conversion between UTC and local time, well, they're doing it wrong, and they really ought to change. * If they know about time zones and the details of time zones (perhaps as part of a user interface that presents these details to users), they definitely need to have a good understanding of the situation in a region that observes DST or some similar switchover. But as Ireland and this thread have shown us, a model based on a simple binary distinction between "standard time" and "DST" doesn't really work. I wonder if, for some of those programs at least, slavishly presenting Ireland as standard=GMT,DST=UTC+1=IST doesn't cause those programs to do precisely the wrong thing? I wonder if a different choice for "DST" mapping (or a different API) wouldn't serve those programs' needs better? * If they're doing something else, I'd really like to know what it is. I guess my bottom line is, again, to wonder what preserving the status quo for Java DST indications actually accomplishes. Yes, it upholds (some part of) a standardized API, and interface stability is obviously good. But in the last analysis, does a Java program that cares abut DST *really* want to be told that a timestamp in the summer in Ireland does use it, or would it rather be told something else?