[GTER] Proposta de padronização
Jorge Godoy
godoy at g2ctech.com
Mon Oct 18 21:36:16 -03 2004
Danton Nunes <danton at inexo.com.br> writes:
> não é função do GTER definir isso. o propóxito desta discussão é extremamente
> limitado, porém muito útil: definir designação (siglas) definitivas e para
> serem usadas em comum acordo para as zonas de tempo do Brasil. Ninguém aqui
> vai se arvorar a definir quem e quando entra no horário de verão, até porque
> não é do nosso bico. fazer com que isso não fique essa zona que é hoje é
> trabalho político (lobby).
Você está afirmando exatamente a mesma coisa que eu afirmei. :-) Se
você ler minhas mensagens sem colocar-se na defensiva ou tentar
encontrar duplos sentidos você vai ver isso.
> mas BRT/BRST não serve. como disse isso designa UM fuso, nós temos quatro,
> portanto precisa mais três siglas. Não acho BRT-1 uma coisa adequada, mas como
> eu mesmo disse, ainda não é hora de chegar a esse detalhe.
Você poderia, então, ser mais claro no que deseja. Uma maneira é
elaborar um "plano de ação", para que possamos definir o assunto e
sabermos o que é discutível ali e o que é discutível no futuro.
Eu proponho:
1. Discutir o que deseja-se ter.
* Configurações para a definição automática e única de horas e
zonas de fuso horário (sem nomenclatura)
Justificativa: A automação faz-se necessária por motivos óbvios
de facilidade e agendamento de mudança de
horário, sem entrar no mérito da segurança. A
não ambigüidade de nomenclaturas permite a
análise e o rápido reconhecimento de uma zona de
fuso horário, bem como a aplicação de conversão
automática para a zona de fuso onde encontra-se o
usuário.
* Organização e separação de forma que se um Estado mudar de zona
de fuso não se perca o histórico de anos anteriores para ele
Justificativa: A preservação do histórico faz-se necessária para
obter relatórios consistentes. Se for alterado o
arquivo de configuração, passa-se a usar
informações que podem não condizer com a
realidade daquele Estado em um dado ano (e.g. o
Estado não participava de horário de verão e foi
incorporado a uma zona de tempo que participava
em um ano qualquer, é necessário informar que
apenas a partir daquele ano ele participa do
horário de verão e não nos outros anos
anteriores; o mesmo vale para um Estado que tinha
horário de verão e passa a não mais participar
dele).
* A documentação consistente e retrocedendo o máximo possível
(creio ser possível levantar 100% das ocorrências) de todas as
mudanças e datas de entrada / saída de horário de verão para
cada Estado brasileiro
Justificativa: É possível realizar um levantamento histórico e
processar-se informações usando os recursos
computacionais do próprio sistema, já com as
devidas correções de horário de verão
aplicadas, independente do ano em que são
consideradas as informações
* Definição de siglas para as zonas de fuso horário em horário
padrão
Justificativa: Após definidos os quesitos anteriores é possível
discutir-se como serão representadas as
diferentes zonas de fuso horário existentes no
país, bem como definir regras para a composição
de novas zonas caso venham a ser criadas ou haja
alguma alteração futura. Deve-se padronizar o
tamanho desta representação (tamanhos mínimo e
máximo).
* Definição de qual será o modificador -- ou qual a nova
representação -- para o horário de verão, bem como sua posição
dentro da zona de fuso horário padrão
Justificativa: Define-se se haverá uma nova representação ou um
modificador qualquer para as zonas de fuso
horário, bem como a posição deste dentro da
representação padrão -- se aplicável.
* Definição de responsabilidades e procedimentos para a realização
de alterações
Justificativa: Nenhuma solução será definitiva ou isenta de
erros. É preciso ter os contatos para
apresentação e notificação de falhas, é preciso
ter as responsabilidades definidas para que os
arquivos e informações não sejam alterados por
qualquer pessoa e é preciso definir um fluxo para
a tomada de decisões e elaboração de novas
definições.
2. Documentar as discussões e decisões
Justificativa: A formalização em um documento escrito permitirá
uma checagem mais voltada à implementação, bem como
a revisão de conceitos, suposições, assumpções e
outros.
3. Implementar o que foi documentado
Justificativa: Deve-se implementar estritamente o que foi
documentado. Se nesta etapa verificar-se alguma
falha, deve-se procurar primeiro corrigir a
documentação e só depois corrigir a implementação.
A documentação é autoritária e representa a
interface e a maneira mais portável de
implementar-se as definições em todo e qualquer
sistema operacional. As implementações são
dependentes de sistemas e/ou plataformas, reduzindo
sua portabilidade.
>> Não estou falando de início e fim! Isso é ainda *outra* questão. Estou
>> falando de *quais* Estados fazem parte da regra. Há uma variação
>> política grande onde uns entram, outros não, no ano seguinte uns +
>> outros entram e "outros ainda" não, etc.
>
> também não é de nossa competência, embora tenhamos um monte de motivos para
> que o horário de verão fique estabelecido com uma regra permanente tanto no
> tempo quanto no espaço.
Vide comentário inicial. O seu "também" refere-se a absolutamente a
mesma coisa.
>> A questão de quem entra ou não é que é política e é mutável. O quando
>> inicia e quando termina é o de menos, pois há uma antecedência aceitável
>> na determinação das datas, permitindo alterações nos arquivos.
>
> não é de menos, não. seria tão bom se fosse uma regra tipo "entra no segundo
> domingo depois do equinócio, sai no segundo domingo antes do outro equinócio"
> gravada em pedra, indelével e só alterada por 9/10 do congresso mais
> plebiscito.
:-) Seria. Mas não é assim. Para isso só com algum político apoiando
esta medida. E isso se não contradisser nada da Constituição...
Sds,
--
Godoy. <godoy at g2ctech.com>
Consultoria e serviços em redes Linux, FreeBSD e Windows.
Desenvolvimento de software e projetos. Treinamentos.
Telefones: +55 (41) 8807-1545 / +55 (41) 362-7020
Curitiba, Paraná - Brasil http://www.g2ctech.com
More information about the gter
mailing list