Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • O octomon
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 2
    • Issues 2
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • FUSS
  • octomon
  • Issues
  • #6

Closed
Open
Created Jul 24, 2013 by Mark Caglienzi@markDeveloper

USE_TZ, datetime, e fusi orari

Django di default setta USE_TZ=True nel settings.py.
Leggendo nella documentazione vedo che con il supporto TZ attivo, Django usa orari UTC internamente e nel database, e presenta nei template i valori rapportati al fuso orario dell’utente.

Facendo la parte degli allarmi, mi sono accorto che vedevo gli orari spostati avanti di 2 ore rispetto al sito in turbogears.
Ho dedotto che Django interpretasse i valori nel database MySQL come UTC, aggiungesse le 2 ore durante la visualizzazione nel template, e che il database MySQL avesse gli stessi valori che poi vengono visualizzati dai template dell’applicazione turbogears.

Nel commit 09a1d475 ho settato USE_TZ=False e ora gli orari visualizzati da Django e da turbogears combaciano.

È una soluzione corretta, oppure serve un supporto TZ più avanzato, e quindi si deve risettare USE_TZ=True e trovare un’altra maniera per portare avanti le cose?
Ho agito così per fare in modo che comunque Django non salvasse valori diversi da quelli visualizzati a schermo, un domani che l’applicazione sarà in produzione, per evitare di avere il database con i valori vecchi in localtime e quelli nuovi in utc.

Assignee
Assign to
Time tracking