FW: About rules for Brazil

[Paulo Alexandre Pinto Pires]

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.