Solipsism Gradient

I’ve downloaded Safari, Apple’s new web browser for Mac OS X, just after yesterday’s MacWorld keynote. Despite breaking Apple’s previous record for downloads – meaning that their servers were under an unprecedented load – it came in at full speed on my 256K ADSL connection.

Anyway, I’ve been using it quite a lot and once they fix a few bugs it should be solid enough to displace Internet Explorer for most purposes.

If you’re using Safari, you may be interested in David Hyatt’s weblog. David worked on Chimera and is now one of the principal Safari developers.

…yeah, right.

A report by Giga Research predicts that Apple will migrate to Intel CPUs by the end of 2003. 🙄

The fact that such silly predictions get any media space at all is well explained by Robert X. Cringely in his columns “Eating Our Seed Corn” and “The Case Against Profissionalism”. Apparently the dubious approach of “maximizing shareholder value” just in time for the next quarterly report is not only becoming standard practice – industry analysts now consider this so obvious that they downgrade companies that have a broader, long-term vision of their mission.

To get the real story, read Ars Technica‘s article about IBM’s PowerPC 970. I’ve just written a similar piece for Macmania magazine.

Early in 1984 I made my first trip to the US to buy the Macintosh 128K, which had been released a few months before. Some friends I met at the airport scoffed at the idea, saying that Apple was dying and would either fold or be acquired by General Electric. 😆

Well, more than 18 years later, Apple is still dying – and it will still be dying for many years to come. Check out MacObserver’s Apple Death Knell Counter page to keep up with the predictions of doom.

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…