John Cowan wrote:
However, I think the important point is that the database not impose guesses about the utterly uncertain future. It is fair enough to guess that U.S. DST will stay the same, since it has been quite stable. But guessing that next year in Brazil will be like last year, when last year was not like the year before, and so on, strikes me as bogus.
In short, I agree that "only" should be the rule here.
That what I wanted to mean, and failed to state as clearly as you did.
A similar situation obtains in Israel, where the guesses after 2004 are quite arbitrary. However, for the few applications that need access to future civil time (planning airplane trips?) I think it better to have a good guess than to guess that there will be no DST at all.
I see your point, but in fact airplane trips are *not* the only case. Any time you make an appointment to do something or meet someone in the future, you are implicitly making it in civil time for the place of the appointment. If I say to someone "Meet me under the Waverley [that's a place in Manhattan] at midnight, New Year's Eve 2004" , then the appointment is set for midnight *local time* whatever that may be. For a more commercial example, when a stock tender or a futures option expires as of 5 PM, New York time, on such-and-such a day, that means at whatever GMT time Congress decrees is equal to 5 PM New York time *as of that day*.
I was more concerned about much simpler things. There are some computer systems and applications where time has a central role. Some of those applications must interface with real people, both on input and on output, and real people (even technicians) are not familiar with time_t, GMT or UTC. The user may input time and not have the expected action happen at the expected time because of bad assumptions about DST (assuming no DST at all among those assumptions). Many applications also have design problems that become evident when crossing DST start/end borders, regardless of when time shifts actually happen -- even standard UNIX date(1) is DST unfriendly. Another problem is that tz repository was only updated (2002d) _after_ DST begun for users of 2002c(timestamp for ftp://elsie.nci.nih.gov/pub/tzdata_2002d.tar.gz is 2002/10/15, while DST started at 2002/10/13 03:00:00 GMT for tzdata 2002c), because of a rule that should have been applied only last year. This fault, however, is not solely TZ people's; related information simply wasn't where people expected it to be (Brazilian National Observatory's (ON) web site was the traditional source, but elsie.nci.nih.gov was also outdated). Only by digging the web could I find the information I wanted, just a couple of days before brazilian clocks would get wrong time. -- Pappires ... Qui habet aurem audiat quid Spiritus dicat ecclesiis.