Solipsism Gradient

Small yellow mushrooms grow from a clump of burned vegetation.

Although it rained frequently during our stay, this region is known for long dry periods and brushfires are very common.

This small bridge crosses a small creek just before a double waterfall. The water has high iron content and has a dark reddish tint.

The whole region is infested with termites, so wooden structures are shortlived; this bridge has been rebuilt a few years ago.

This flower measures about 5 mm across and seems to be pretty typical for the Jequitinhonha region.

It was very windy so I had to hold the stem with my other hand and set the shutter speed to 1/2000 sec. This also had the desired result of blurring the background.

Here [in following posts] are the promised pictures – or at least, the better ones , from my New Year’s vacation at Milho Verde, near the source of the Jequitinhonha River in the interior of Minas Gerais.

Publiquei todos os episódios arquivados do Zé Megabyte. Havia mais um ou dois mas infelizmente estão perdidos… se alguém tiver, por favor me mande!

Update: os episódios agora estão na ordem certa (não invertida). Desculpem a falha…

Comecei a repostar em tópico separado as aventuras de Zé Megabyte, uma história em quadrinhos que publiquei na década de 80.

This may come as a surprise to US-based readers, but Mac OS X daylight saving time (DST) algorithms are broken. (Yes, I’ll be filing a bug as soon as I have all the information together.)

Basically, the BSD underpinnings of Mac OS X use the standard timezone files in /usr/share/zoneinfo. There’s a symbolic link at /etc/localtime which points to the correct TZ file; in my case, /usr/share/zoneinfo/Brazil/East. So far so good…

Last weekend all Macs in Brazil running Mac OS X suddenly shifted one hour ahead. Apparently no one had thought of telling Apple that the official start of DST in Brazil had been postponed from Oct. 13 to Nov. 3. No one’s sure exactly why; it probably had to do with the presidential elections, or the unseasonably hot weather, or the dropping exchange rate, or all of those…

Naturally, I thought this would be simple to fix; just fix the TZ source file, recompile it with zic, distribute a patch, and presto. Little did I know. First of all, getting hold of the original TZ source file wasn’t easy. The updated files are supposed to be available at ftp://elsie.nci.nih.gov/pub/, which seems to be permanently down. Googling for the files yielded only a few hits, most of which hadn’t been updated since 1999 or 2000.

The obvious place to find them should have been Apple’s Darwin site. However, there’s no easy index to find which files are in which source module, and I had neither time nor bandwidth to download the whole 600+MB thing. Looking in Libc and a dozen other likely places yielded nothing.

I finally chose one of the latest files I could find and updated it according to the government’s official site. There were many small errors, but finally it seemed to be working and I published a patch.

A few days later some readers sent me mail, complaining that the Finder’s timestamps were being set one hour ahead. Entourage was also setting appointments one hour ahead, and similar reports came in for some other Carbon applications.

I’m still investigating this, but apparently the Finder (and some other Carbon apps) still use the old-style APIs to convert UTC to local time. These APIs, instead of using the BSD tables, apparently still use some classic database. Needless to say, there seems to be no easy method for synching this database with the BSD information…

One further problem is that the classic database is using an outdated rule of thumb for Brazil: DST is supposed to start on the first Sunday in October. That has indeed been the case for a couple of years, but not lately… anyway, Brazil is one of those countries where the actual DST dates are set anew every year by government decree. So any such rule of thumb will be more times wrong than right.

Unfortunately, the standard BSD TZ files are in a binary format. This is clearly one place where Apple should break with the standard and go to XML files. Standard Unix tools shouldn’t read those files directly anyway, as there’s an API to get specific information from them.

Last night I did a check on many well-known timezone sites. Most of them still have the old, incorrect, Oct. 13 date stored and therefore incorrectly tell users that DST is active in Brazil. A few still use the “first Sunday in October” rule and therefore have been wrong since Oct. 6! Only one lone site had correct information. All sites, without fail, are applying DST to all 4 of Brazil’s timezones, which is also wrong; only the Brazil/East zone applies DST (some states are exceptions – rarely the same ones).

The same problem, of course, hit many Internet provider’s servers, as they mostly use Linux. The standard fix has usually been to manually set the server’s clock, instead of fixing the TZ data. Those few servers that synch to time servers have to switch timezones instead. These quick-and-dirty fixes further confuses matters, as some software which explicitly checks for DST will continue to show the wrong time.

Finally, there seems to be a large-scale misconception that there are no TZ tables inside each computer, and that DST changes are broadcast by time servers; some people wrote me complaining that they had checked out several time servers, and that even the Brazilian servers were wrong! Of course, that’s not the case; time servers broadcast UTC time and this is converted to local time inside each computer.

Update: It seems that two routines in the Date&Time utilities, which convert between Local time and UTC, use fixed tables built into the CarbonCore framework executable, instead of the TZ tables.

I’ll be updating this post as I find out more clues… stay tuned!

O horário de verão no Brasil foi alterado na última hora, como sempre acontece. Pegue o pacote de atualização aqui! Se você prefere fazer pelo Terminal, use esse arquivo fonte (instruções inclusas).

Confira com o site do Governo, por via das dúvidas…