Em relação a hora do servidor, é provável que ele já tenha armazenado
essas mudanças nos arquivos de zoneinfo (/usr/share/zoneinfo). Para
atualizar esse banco é só atualizar o pacote tzdata.
E com o tzdump você pode verificar se está ok. No meu server por
exemplo, quando rodo 'zdump -v America/Sao_Paulo | grep 2010' (a zona
America/Sao_Paulo é a que o Rails maapeia para Brasilia), tenho a
seguinte saída:
America/Sao_Paulo Sun Feb 21 01:59:59 2010 UTC = Sat Feb 20 23:59:59
2010 BRST isdst=1 gmtoff=-7200
America/Sao_Paulo Sun Feb 21 02:00:00 2010 UTC = Sat Feb 20 23:00:00
2010 BRT isdst=0 gmtoff=-10800
America/Sao_Paulo Sun Oct 17 02:59:59 2010 UTC = Sat Oct 16 23:59:59
2010 BRT isdst=0 gmtoff=-10800
America/Sao_Paulo Sun Oct 17 03:00:00 2010 UTC = Sun Oct 17 01:00:00
2010 BRST isdst=1 gmtoff=-7200
Ou seja, nesse ano o horário de verão acabou em 21 fevereiro e
começará em 17 de outubro.
O Rails por padrão tem uma classe TimeZone que não leva em
consideração o horário de verão ou DST (Daylight Saving Time). Mas, se
ele pegar essa info do SO e este já levar em consideração o DST (como
no exemplo que mostrei), acredito que você não precisa fazer nada.
Exceto se seu público alvo for algum fuso-horário do Brasil que seja
diferente da de São Paulo (como o Acre ou Fernando de Noronha) ou que
não tenha horário de verão (regões Norte e Nordeste). Nesse caso você
pode tentar mudar a string padrão do Rails para a equivalente no
timezone do servidor.
Outra alternativa é usar diretamente gem tzinfo (que usa o mesmo banco
de dados do tzdata.