Bug 466820

Sorry, not is a good idea back the clock incorrect adjusted by tzdata, because almost users, probably, changed clock back manually.

The change you refer to was introduced in tzdata-2008f, which went out to Fedora 9 stable on 2008-09-24[1].  There was another change after that, fixing Brazil DST transitions for times in future (where it collided with The Carnival before); that was tzdata-2008g, released 2008-10-09[2].  So you should be all set (but apparently you are not, for some reason).

Can you send me the output of following commands?
 - rpm -q tzdata
 - rpm -V tzdata
 - cat /etc/sysconfig/clock
   - there should be some ZONE setting in that file, e.g. ZONE=America/Sao_Paulo
     From now on, I'll refer to that zone by $TZ
 - md5sum /etc/localtime /usr/share/zoneinfo/$TZ

I'm suspecting that glibc trigger didn't update /etc/localtime, the above should either confirm or dispel that suspicion.

[1] https://admin.fedoraproject.org/updates/F9/FEDORA-2008-8317
[2] https://admin.fedoraproject.org/updates/F9/FEDORA-2008-8714

[fabricio@localhost ~]$ rpm -q tzdata
tzdata-2008g-1.fc9.noarch
[fabricio@localhost ~]$ rpm -V tzdata
[fabricio@localhost ~]$ cat /etc/sysconfig/clock
# The ZONE parameter is only evaluated by system-config-date.
# The time zone of the system is defined by the contents of /etc/localtime.
ZONE="America/Sao Paulo"
[fabricio@localhost ~]$ md5sum /etc/localtime /usr/share/zoneinfo/America/Sao_Paulo
7613c2153980b60de4fb74f692d7c1eb  /etc/localtime
7613c2153980b60de4fb74f692d7c1eb  /usr/share/zoneinfo/America/Sao_Paulo
[fabricio@localhost ~]$

md5sums of your localtime and Sao_Paulo files match with md5sum on my installation.  That pretty much confirms that there was no problem during update, nor was there tampering with the files.  On my installation, zdump of Sao_Paulo shows the following:

$ /usr/sbin/zdump -v /usr/share/zoneinfo/America/Sao_Paulo | grep 2008
/usr/share/zoneinfo/America/Sao_Paulo  Sun Feb 17 01:59:59 2008 UTC = Sat Feb 16 23:59:59 2008 BRST isdst=1 gmtoff=-7200
/usr/share/zoneinfo/America/Sao_Paulo  Sun Feb 17 02:00:00 2008 UTC = Sat Feb 16 23:00:00 2008 BRT isdst=0 gmtoff=-10800
/usr/share/zoneinfo/America/Sao_Paulo  Sun Oct 19 02:59:59 2008 UTC = Sat Oct 18 23:59:59 2008 BRT isdst=0 gmtoff=-10800
/usr/share/zoneinfo/America/Sao_Paulo  Sun Oct 19 03:00:00 2008 UTC = Sun Oct 19 01:00:00 2008 BRST isdst=1 gmtoff=-7200

Which means that the transition shouldn't have occurred until Oct 19.  That it did occur can have several reasons.
 1) you didn't have your tzdata updated to the version higher than 2008e soon enough (and the rule Oct Sun>=8 had taken effect)
 2) you did have all the updates, but the hitch occured that I was trying to discover above using the md5 sums.  But you updated tzdata after that, and the hitch is no longer visible.

Whichever is the case, the bug is not on side of tzdata, we're ready for Brazil DST change a couple releases already.

I remember that at October 10 my system was updated to tzdata-2008g and at October 12 00:00 my system entered in daylight saving time.

So does your computer think you are in DST right now?  You can find out like this:
$ date +%Z
If it shows BRST, you are in daylight saving period.  If it's BRT, you are not.  If it's something else, you are in a wrong zone :)

If you are in BRT, what happened between now and back when it thought you are in the DST?  Which event caused the time to become "normal" again?  I.e. what fixed the bug?

And how did you find out that you are in the DST period?  Was it because of e.g. Gnome clocks, or simply typing date into the console?  I'm asking because some applications have had their own timezone support, e.g. Java used to have DST transitions hard-coded until recently, and there might still be more cases like this.

If you are in BRST, we have a very strange situation, because your files seem to be right.  We will have to dig a bit deeper in that case.

I don't understand:

[fabricio@localhost ~]$ date
Qua Out 15 20:57:15 BRT 2008
[fabricio@localhost ~]$ /usr/sbin/zdump -v /usr/share/zoneinfo/America/Sao_Paulo | grep 2008
/usr/share/zoneinfo/America/Sao_Paulo  Sun Feb 17 01:59:59 2008 UTC = Sat Feb 16 23:59:59 2008 BRST isdst=1 gmtoff=-7200
/usr/share/zoneinfo/America/Sao_Paulo  Sun Feb 17 02:00:00 2008 UTC = Sat Feb 16 23:00:00 2008 BRT isdst=0 gmtoff=-10800
/usr/share/zoneinfo/America/Sao_Paulo  Sun Oct 19 02:59:59 2008 UTC = Sat Oct 18 23:59:59 2008 BRT isdst=0 gmtoff=-10800
/usr/share/zoneinfo/America/Sao_Paulo  Sun Oct 19 03:00:00 2008 UTC = Sun Oct 19 01:00:00 2008 BRST isdst=1 gmtoff=-7200

I thinked that my computer is in DST period because the clock was advanced one hour. I don't know if was BRT or BRST, sorry.

I tried to simulate same condition adjusting the clock to October 11 23:59:00 and the system not advanced 1 hour at October 12 00:00:00.
I really don't understand what was happened.

Neither do I.  I'm afraid it's not possible to discover what happened and why anymore.