[python-brasil] SQLite3 e Data/Hora
Daniel Gonçalves
Defini uma tabela que utiliza um campo data/hora, no SQLite3. Python
possui um adaptador e um conversor para date/datetime, mapeados para
os tipos "DATE" e "TIMESTAMP" respectivamente. Entretando, ao definir
a tabela, eu costumo especificar um valor default como por exemplo:
CREATE TABLE teste (quando TIMESTAMP NOT NULL DEFAULT datetime('now'));
OK. Se eu emito um SELECT datetime('now') ele retorna a data correta,
mas a hora, 3 horas adiante. Procurei na documentação, tanto do Python
quando do SQLite, e não encontrei nada a respeito de determinar o
locale. Então pensei em fazer como sugerem os exemplos da documentação
do SQLite e fiz assim:
CREATE TABLE teste (quando TIMESTAMP NOT NULL DEFAULT datetime('now',
'-3 hour'));
Funciona, mas está cheirando a gambiarra. Alguém sabe de alguma
solução para isso? Penso que a solução ideal seria poder determinar o
locale, mas não achei como fazer isso.
--
Daniel Gonçalves
Base4 Sistemas Ltda.
[www.base4.com.br]
[twitter.com/spanazzi]
------------------------------------
,-----------------------------------------------------------.
| Antes de enviar um e-mail para o grupo leia: |
| http://www.pythonbrasil.com.br/moin.cgi/AntesDePerguntar |
| E se você é usuário do BOL lembre-se de cadastrar o |
| e-mail do grupo na lista branca do seu sistema anti-spam. |
`-----------------------------------------------------------´Links do Yahoo! Grupos
<*> Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/python-brasil/
<*> Para sair deste grupo, envie um e-mail para:
python-brasi...@yahoogrupos.com.br
<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html
Paulo Eduardo Neves
parece estar certo. A hora interna está sendo gravada em GMT. Isto evita
confusões como ter objetos criados no futuro quando se entra em horário de
verão (sim, já aconteceu comigo:-)
Em 22 de julho de 2010 14:42, Daniel Gonçalves <dan...@base4.com.br>escreveu:
> Olá Todos,
> Defini uma tabela que utiliza um campo data/hora, no SQLite3. Python
> possui um adaptador e um conversor para date/datetime, mapeados para
> os tipos "DATE" e "TIMESTAMP" respectivamente. Entretando, ao definir
> a tabela, eu costumo especificar um valor default como por exemplo:
>
> CREATE TABLE teste (quando TIMESTAMP NOT NULL DEFAULT datetime('now'));
>
> OK. Se eu emito um SELECT datetime('now') ele retorna a data correta,
> mas a hora, 3 horas adiante. Procurei na documentação, tanto do Python
> quando do SQLite, e não encontrei nada a respeito de determinar o
> locale. Então pensei em fazer como sugerem os exemplos da documentação
> do SQLite e fiz assim:
>
> CREATE TABLE teste (quando TIMESTAMP NOT NULL DEFAULT datetime('now',
> '-3 hour'));
>
> Funciona, mas está cheirando a gambiarra. Alguém sabe de alguma
> solução para isso? Penso que a solução ideal seria poder determinar o
> locale, mas não achei como fazer isso.
>
[As partes desta mensagem que não continham texto foram removidas]
Roger Demetrescu
> Valeu Paulo, mas, que estranho! Deixa eu ver se eu entendi: ele *sempre* vai
> usar GMT para retornar o horário... quer dizer que:
>
> SELECT datetime('now');
>
> Vai sempre retornar o horário GMT? E como ele decide isso, quero dizer, ele
> tem que saber o meu horário e o meu locale, né?!
Daniel, creio que você está confundindo alguns conceitos...
O locale diz respeito a diversas configurações de idioma, tais como
formato de data e hora, números, valores financeiros, etc...
Existe uma outra coisa que é o fuso horario (timezone) onde você está.
Tanto um computador no Acre como em São Paulo podem usar o mesmo
locale pt-BR, mas estão em fusos horários diferentes. Seus "horários
locais" serão diferentes, mas o horário UTC (ou GMT) deverá ser o
mesmo.
Se você estiver usando linux, experimente executar os comandos:
linux1:~# date
Sex Jul 23 18:05:22 BRT 2010
linux1:~# date -u
Sex Jul 23 21:05:24 UTC 2010
Repare nas 3 horas de defasagem (alias, percebi que o relógio esta
errado... preciso arrumar isso... :))
Repare também nesse "BRT" e no "UTC"
Bom, em relação ao banco de dados, não tenho muita experiencia com
sqlite, mas no postgres existem tipos diferentes de coluna, que podem
armazenar um horario levando em consideração o timezone ou não:
http://www.postgresql.org/docs/8.4/static/datatype-datetime.html
Uma das vantagens de se usar o horario com timezone, por exemplo, é
rastrear a movimentação de um hacker entre diversas maquinas. Imagine
um hacker acessando uma maquina no Brasil, depois a partir desta, ele
invade uma maquina na Itália e desta ele vai para uma máquina no
Chile, e depois para China....
Imagine alguém olhando os logs dessas maquinas todas.. .se elas
estiverem registrando os horários locais, o analista pode acabar
concluindo que a ordem dos ataques foi direfente do que aconteceu na
realidade.
Bom, é isso... outras pessoas mais sábias se manifestarão, tenho certeza... :)
[]s
Roger
Daniel Gonçalves
usar GMT para retornar o horário... quer dizer que:
SELECT datetime('now');
Vai sempre retornar o horário GMT? E como ele decide isso, quero dizer, ele
tem que saber o meu horário e o meu locale, né?!
Em 22 de julho de 2010 18:30, Paulo Eduardo Neves
<paulo...@gmail.com>escreveu:
>
>
> Caro,
> parece estar certo. A hora interna está sendo gravada em GMT. Isto evita
> confusões como ter objetos criados no futuro quando se entra em horário de
> verão (sim, já aconteceu comigo:-)
>
> Em 22 de julho de 2010 14:42, Daniel Gonçalves <dan...@base4.com.br<daniel%40base4.com.br>
> >escreveu:
>
>
> > Olá Todos,
> > Defini uma tabela que utiliza um campo data/hora, no SQLite3. Python
> > possui um adaptador e um conversor para date/datetime, mapeados para
> > os tipos "DATE" e "TIMESTAMP" respectivamente. Entretando, ao definir
> > a tabela, eu costumo especificar um valor default como por exemplo:
> >
> > CREATE TABLE teste (quando TIMESTAMP NOT NULL DEFAULT datetime('now'));
> >
> > OK. Se eu emito um SELECT datetime('now') ele retorna a data correta,
> > mas a hora, 3 horas adiante. Procurei na documentação, tanto do Python
> > quando do SQLite, e não encontrei nada a respeito de determinar o
> > locale. Então pensei em fazer como sugerem os exemplos da documentação
> > do SQLite e fiz assim:
> >
> > CREATE TABLE teste (quando TIMESTAMP NOT NULL DEFAULT datetime('now',
> > '-3 hour'));
> >
> > Funciona, mas está cheirando a gambiarra. Alguém sabe de alguma
> > solução para isso? Penso que a solução ideal seria poder determinar o
> > locale, mas não achei como fazer isso.
> >
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>
--
Daniel Gonçalves
Base4 Sistemas Ltda.
[www.base4.com.br]
[twitter.com/spanazzi]
Daniel Gonçalves
Entendi, minha preocupação era não fazer besteira, e é justamente o que o
documento (link na resposta do stackoverflow) indica que deve ser feito:
descontar/acrescentar o offset do seu timezone (se você souber). Obrigado
pela resposta.
@Roger Demetrescu
Obrigado pela resposta. Eu estava realmente confundindo o locale com o
timezone. Sua explicação foi muito clara, não deixou dúvida.
Em 23 de julho de 2010 17:53, Paulo Eduardo Neves
<paulo...@gmail.com>escreveu:
>
>
> Antes quero dizer que mexi bem pouco com SQLite e nunca me preocupei
> com a hora e data. Talvez não seja a melhor para te aconselhar:-)
>
> Não estou dizendo que ele sempre vai *retornar* em GMT, mas sim que
> ele armazena internamente como GMT e que ao fazer isto ele está
> evitando que você tenha problemas.
>
> O Sqlite sabe o timezone pois isto está configurando em seu micro.
>
> Pelo visto você tem mesmo que especificar o timezone antes de mostrar
> qualquer datetime para o usuário:
> SELECT DATETIME(col, 'BRT')
> Veja o que achei:
>
> http://stackoverflow.com/questions/381371/sqlite-current-timestamp-is-in-gmt-not-the-timezone-of-the-machine
>
> em Python você pode pegar o nome da timezone pelo módulo time:
> In [16]: time.tzname
> Out[16]: ('BRT', 'BRST')
>
> O raciocínio é como o de trabalhar com Unicode e os encodings. A
> representação interna é toda no GMT (ou UTC que é o padrão hoje em
> dia). Ao ler um dado do usuário, você converte para UTC, faz todas as
> operações e comparações internas em UTC, e ao mostrar de volta para o
> usuário converte para seu timezone.
>
> Em 23 de julho de 2010 16:55, Daniel Gonçalves <dan...@base4.com.br<daniel%40base4.com.br>>
> escreveu:
>
> >
> > Valeu Paulo, mas, que estranho! Deixa eu ver se eu entendi: ele *sempre*
> vai
> > usar GMT para retornar o horário... quer dizer que:
> >
> > SELECT datetime('now');
> >
> > Vai sempre retornar o horário GMT? E como ele decide isso, quero dizer,
> ele
> > tem que saber o meu horário e o meu locale, né?!
> >
> > Em 22 de julho de 2010 18:30, Paulo Eduardo Neves
> > <paulo...@gmail.com <pauloneves%40gmail.com>>escreveu:
> Paulo Eduardo Neves
> http://www.Mosquito.pro.br
Paulo Eduardo Neves
com a hora e data. Talvez não seja a melhor para te aconselhar:-)
Não estou dizendo que ele sempre vai *retornar* em GMT, mas sim que
ele armazena internamente como GMT e que ao fazer isto ele está
evitando que você tenha problemas.
O Sqlite sabe o timezone pois isto está configurando em seu micro.
Pelo visto você tem mesmo que especificar o timezone antes de mostrar
qualquer datetime para o usuário:
SELECT DATETIME(col, 'BRT')
Veja o que achei:
http://stackoverflow.com/questions/381371/sqlite-current-timestamp-is-in-gmt-not-the-timezone-of-the-machine
em Python você pode pegar o nome da timezone pelo módulo time:
In [16]: time.tzname
Out[16]: ('BRT', 'BRST')
O raciocínio é como o de trabalhar com Unicode e os encodings. A
representação interna é toda no GMT (ou UTC que é o padrão hoje em
dia). Ao ler um dado do usuário, você converte para UTC, faz todas as
operações e comparações internas em UTC, e ao mostrar de volta para o
usuário converte para seu timezone.
Paulo Eduardo Neves
http://www.Mosquito.pro.br
Daniel Gonçalves
Em SQLite, a string 'BRT' não rolou. A sintaxe que funcionou aqui pra mim:
CREATE TABLE tabname (..., col TIMESTAMP NOT NULL DEFAULT
CURRENT_TIMESTAMP);
SELECT datetime(col, 'localtime') AS colname FROM tabname;
Daí funcionou certinho. Obrigado, Paulo :-)
Em 23 de julho de 2010 18:37, Paulo Eduardo Neves
<paulo...@gmail.com>escreveu:
>
>
> Em 23 de julho de 2010 18:23, Daniel Gonçalves <dan...@base4.com.br<daniel%40base4.com.br>>
> escreveu:
>
> > @Paulo Eduardo Neves
> > Entendi, minha preocupação era não fazer besteira, e é justamente o que o
> > documento (link na resposta do stackoverflow) indica que deve ser feito:
> > descontar/acrescentar o offset do seu timezone (se você souber). Obrigado
> > pela resposta.
>
> Não faça isto isto. Especifique o timezone como falei:
> SELECT DATETIME(col, 'BRT')
>
> Senão vai melar quando entrar no horário de verão
>
> --
> Paulo Eduardo Neves
> http://www.mosquito.pro.br
Paulo Eduardo Neves
> @Paulo Eduardo Neves
> Entendi, minha preocupação era não fazer besteira, e é justamente o que o
> documento (link na resposta do stackoverflow) indica que deve ser feito:
> descontar/acrescentar o offset do seu timezone (se você souber). Obrigado
> pela resposta.
Não faça isto isto. Especifique o timezone como falei:
SELECT DATETIME(col, 'BRT')
Senão vai melar quando entrar no horário de verão
--
Paulo Eduardo Neves
http://www.mosquito.pro.br