Presta atención porque en este post encontrarás el arreglo que buscas.Este artículo fue aprobado por nuestros especialistas para asegurar la calidad y veracidad de nuestro post.
Solución:
http://www.postgresql.org/docs/8.3/interactive/datatype-datetime.html#DATATYPE-TIMEZONES
Todas las fechas y horas con reconocimiento de zona horaria se almacenan internamente en UTC. Se convierten a la hora local en la zona especificada por el parámetro de configuración de zona horaria antes de mostrarse al cliente.
La única forma de almacenarlo con postgresql es almacenarlo por separado.
se da una solución en la respuesta de esta pregunta:
puede eludir eso almacenando todos los objetos de hora (fecha) en su base de datos en UTC y convirtiendo los objetos de fecha y hora ingenuos resultantes en objetos conscientes en la recuperación.
el único inconveniente es que pierde la información de la zona horaria, pero de todos modos probablemente sea una buena idea almacenar sus objetos de fecha y hora en utc.
si le importa la información de la zona horaria, la almacenaría por separado y solo convertiría la utc a la hora local en la última instancia posible (por ejemplo, justo antes de mostrarla)
o tal vez no necesite preocuparse después de todo, y puede usar la información de la zona horaria local de la máquina en la que ejecuta su programa, o el navegador del usuario si es una aplicación web.
Una forma de resolver este problema es usar siempre campos que tengan en cuenta la zona horaria en la base de datos. Pero tenga en cuenta que la misma hora se puede expresar de forma diferente según la zona horaria, y aunque esto no es un problema para las computadoras, es muy inconveniente para nosotros:
2003-04-12 23:05:06 +01:00
2003-04-13 00:05:06 +02:00 # This is the same time as above!
Además, Postgresql almacena todas las fechas y horas conscientes de la zona horaria internamente en UTC. Se convierten a la hora local en la zona especificada por el parámetro de configuración de zona horaria antes de mostrarse al cliente.
En cambio, recomiendo usar UTC marcas de tiempo tanto en la aplicación como en las fechas y horas ingenuas de la zona horaria en la base de datos, y solo las convierte a la zona horaria local de los usuarios antes de que el usuario las vea.
Esta estrategia le permite tener el código más limpio, evitando cualquier conversión y confusión de zonas horarias, y hace que su base de datos y su aplicación funcionen de manera consistente, independientemente de las diferencias de “zona horaria local”. Por ejemplo, es posible que su máquina de desarrollo y su servidor de producción se ejecuten en la nube en diferentes zonas horarias.
Para lograr esto, dígale a Postgresql que desea ver las zonas horarias en UTC antes de inicializar el motor.
En SqlAlchemy lo haces así:
engine = create_engine(..., connect_args="options": "-c timezone=utc")
Y si está usando tornado-sqlalchemy, puede usar:
factory = make_session_factory(..., connect_args="options": "-c timezone=utc")
Dado que usamos todas las zonas horarias UTC en todas partes, simplemente usamos fechas y horas ingenuas de la zona horaria en el modelo:
created_at = Column(DateTime, default=datetime.utcnow)
updated_at = Column(DateTime)
Y lo mismo en caso de que estés usando alambique:
sa.Column('created_at', sa.DateTime()),
sa.Column('updated_at', sa.DateTime()),
Y en el código usa la hora UTC:
from datetime import datetime
...
model_object.updated_at = datetime.now(timezone.utc)
Sección de Reseñas y Valoraciones
Tienes la opción de avalar nuestro cometido poniendo un comentario y puntuándolo te damos la bienvenida.