--- title: "Fuseaux horaires" version: 1.10 locale: fr source: https://docs.djangoproject.com/fr/1.10/topics/i18n/timezones/ canonical: https://djangodocs.dev/fr/1.10/topics/i18n/timezones/ --- # Fuseaux horaires ## Aperçu Lorsque la prise en charge des fuseaux horaires est activée, Django stocke les informations de date/heure en UTC dans la base de données, utilise en interne des objets date/heure conscients de leur fuseau horaire et les convertit dans les gabarits et les formulaires en utilisant le fuseau horaire de l’utilisateur. C’est très pratique si vos utilisateurs sont répartis sur plus d’un fuseau horaire et que vous vouliez afficher les informations temporelles selon l’heure locale de chacun. Même si votre site Web n’est utilisé que dans un seul fuseau horaire, stocker les données en UTC dans la base de données fait partie des bonnes pratiques. La raison principale étant l’heure d’été (Daylight Saving Time - DST). Dans beaucoup de pays, l’heure d’été fait avancer d’une heure au printemps et reculer d’une heure en automne. Si vous travaillez en temps local, vous risquez d’obtenir des erreurs deux fois par année, au moment de la transition (la documentation de [pytz](http://pytz.sourceforge.net/) aborde [ces questions](http://pytz.sourceforge.net/#problems-with-localtime) plus en détails). ce n’est probablement pas un problème pour votre blog, mais c’en est un si vous surfacturez ou sous-facturez vos clients d’une heure, deux fois par année, chaque année. La solution à ce problème est d’utiliser UTC dans le code, et le temps local uniquement lors des interactions avec les utilisateurs du site. La prise en charge des fuseaux horaires est désactivée par défaut. Pour l’activer, définissez [`USE_TZ = True`](/fr/1.10/ref/settings/#std-setting-USE_TZ) dans votre fichier de réglages. L’installation de [pytz](http://pytz.sourceforge.net/) est fortement recommandée, mais n’est pas toujours obligatoire, en fonction du moteur de base de données, du système d’exploitation et du fuseau horaire. Si vous obtenez une exception à la suite de requêtes de dates ou d’heures, essayez de l’installer avant de créer un ticket. C’est aussi simple que : ```console $ pip install pytz ``` > **Note** > > Le fichier `settings.py` créé par défaut par [`django-admin startproject`](/fr/1.10/ref/django-admin/#django-admin-startproject) définit `USE_TZ = True` par commodité. > **Note** > > Il existe également un réglage différent mais lié nommé [`USE_L10N`](/fr/1.10/ref/settings/#std-setting-USE_L10N) qui contrôle l’activation ou non des formats de régionalisation. Voir [Régionalisation des formats](/fr/1.10/topics/i18n/formatting/) pour plus de détails. Si vous êtes empêtré dans un problème particulier, commencez par lire la [FAQ des fuseaux horaires](#time-zones-faq). ## Concepts ### Objets `datetime` naïfs et conscients Les objets [`datetime.datetime`](https://docs.python.org/3/library/datetime.html#datetime.datetime) de Python possèdent un attribut `tzinfo` pouvant être utilisé pour stocker le fuseau horaire, représenté par une instance d’une sous-classe de [`datetime.tzinfo`](https://docs.python.org/3/library/datetime.html#datetime.tzinfo). Lorsque cet attribut est défini et qu’il décrit un décalage horaire, l’objet `datetime` est **conscient**. Dans le cas contraire, il est **naïf**. Vous pouvez utiliser [`is_aware()`](/fr/1.10/ref/utils/#django.utils.timezone.is_aware) et [`is_naive()`](/fr/1.10/ref/utils/#django.utils.timezone.is_naive) pour déterminer si les objets `datetime` sont conscients (aware) ou naïfs. Lorsque la prise en charge des fuseaux horaires est désactivée, Django utilise des objets `datetime` naïfs en heure locale. C’est simple et suffisant dans de nombreux cas. Dans ce mode, pour obtenir le temps actuel, vous écririez : ``` import datetime now = datetime.datetime.now() ``` Lorsque la prise en charge des fuseaux horaires est activée ([`USE_TZ=True`](/fr/1.10/ref/settings/#std-setting-USE_TZ)), Django utilise des objets `datetime` conscients de leur fuseau horaire. Si vote code crée des objets `datetime`, ils devraient également être conscients. Dans ce mode, l’exemple ci-dessus devient : ``` from django.utils import timezone now = timezone.now() ``` > **Warning** > > La manipulation des objets `datetime` conscients n’est pas toujours intuitive. Par exemple, le paramètre `tzinfo` du constructeur standard de `datetime` ne fonctionne pas de manière fiable pour les fuseaux horaires avec heure d’été. L’utilisation de l’heure UTC est généralement sûre ; si vous utilisez d’autres fuseaux horaires, vous devriez lire attentivement la documentation de [pytz](http://pytz.sourceforge.net/). > **Note** > > Les objets [`datetime.time`](https://docs.python.org/3/library/datetime.html#datetime.time) de Python comportent également un attribut `tzinfo`, et PostgreSQL possède un type correspondant `time with time zone` (heure avec fuseau horaire). Cependant, comme l’explique la documentation de PostgreSQL, ce type « prête des propriétés qui font douter de son utilité ». > > Django ne prend en charge que des objets `time` naïfs et génère une exception si vous essayez d’enregistrer un objet `time` conscient, dans la mesure où un fuseau horaire n’a pas de sens pour un objet `time` sans date associée. ### Interprétation des objets `datetime` naïfs Lorsque [`USE_TZ`](/fr/1.10/ref/settings/#std-setting-USE_TZ) vaut `True`, Django accepte encore les objets `datetime` naïfs, afin de préserver la rétrocompatibilité. Lorsque la couche base de données en reçoit un, elle essaie de le rendre conscient en l’interprétant dans le [fuseau horaire par défaut](#default-current-time-zone) et génère un avertissement. Malheureusement, durant les transitions d’heure d’été, certains objets `datetime` n’existent pas ou sont ambigus. Dans de telles situations, [pytz](http://pytz.sourceforge.net/) génère une exception. D’autres implémentations de [`tzinfo`](https://docs.python.org/3/library/datetime.html#datetime.tzinfo), tel que le fuseau local utilisé comme valeur de repli quand [pytz](http://pytz.sourceforge.net/) n’est pas installé, peuvent générer une exception ou renvoyer un résultat imprécis. C’est pourquoi vous devriez toujours créer des objets `datetime` conscients lorsque la prise en charge des fuseaux horaires est activée. En pratique, c’est rarement un problème. Django produit des objets `datetime` conscients dans les modèles et les formulaires, et la plupart du temps, les nouveaux objets `datetime` sont créés à partir d’objets existants par des opérations [`timedelta`](https://docs.python.org/3/library/datetime.html#datetime.timedelta). Le seul objet `datetime` qui est souvent créé dans du code applicatif est l’heure actuelle et [`timezone.now()`](/fr/1.10/ref/utils/#django.utils.timezone.now) fait automatiquement ce qu’il faut. ### Fuseau horaire par défaut et fuseau horaire actuel Le **fuseau horaire par défaut** est le fuseau horaire défini par le réglage [`TIME_ZONE`](/fr/1.10/ref/settings/#std-setting-TIME_ZONE). Le **fuseau horaire actuel** est le fuseau horaire utilisé pour l’affichage. Vous devriez définir le fuseau horaire actuel au fuseau horaire réel de l’utilisateur avec [`activate()`](/fr/1.10/ref/utils/#django.utils.timezone.activate). Sinon, c’est le fuseau horaire par défaut qui est utilisé. > **Note** > > Comme expliqué dans la documentation de [`TIME_ZONE`](/fr/1.10/ref/settings/#std-setting-TIME_ZONE), Django définit des variables d’environnement afin que son processus tourne dans le fuseau horaire par défaut. Ce comportement est indépendant de la valeur de [`USE_TZ`](/fr/1.10/ref/settings/#std-setting-USE_TZ) et du fuseau horaire actuel. > > Lorsque [`USE_TZ`](/fr/1.10/ref/settings/#std-setting-USE_TZ) vaut `True`, ceci est utile pour préserver la rétrocompatibilité avec les applications qui se basent encore sur le temps local. Cepedant, [comme expliqué ci-dessus](#naive-datetime-objects), ce n’est pas totalement fiable et vous devriez toujours travailler avec des objets `datetime` conscients en UTC dans votre propre code. Par exemple, utilisez [`fromtimestamp()`](https://docs.python.org/3/library/datetime.html#datetime.datetime.fromtimestamp) et définissez le paramètre `tz` à [`utc`](/fr/1.10/ref/utils/#django.utils.timezone.utc). ### Sélection du fuseau horaire actuel Le fuseau horaire actuel est l’équivalent de la [langue](/fr/1.10/topics/i18n/#term-locale-name) actuelle pour les traductions. Cependant, il n’y a pas d’équivalent à l’en-tête HTTP `Accept-Language` que Django pourrait utiliser pour déterminer automatiquement le fuseau horaire de l’utilisateur. Au lieu de cela, Django fournit des [fonctions de sélection du fuseau horaire](/fr/1.10/ref/utils/#time-zone-selection-functions). Utilisez-les pour bâtir une logique de sélection du fuseau horaire qui a du sens dans votre situation. La plupart des sites Web se préoccupant des fuseaux horaires ne font que demander aux utilisateurs leur fuseau horaire de domicile et stockent cette information dans le profil des utilisateurs. Pour les utilisateurs anonymes, ils utilisent le fuseau horaire de la majorité de leur public ou l’heure UTC. [pytz](http://pytz.sourceforge.net/) propose des [utilitaires](http://pytz.sourceforge.net/#helpers), comme une liste de fuseaux horaires par pays, qu’il est possible d’exploiter pour faire une présélection des choix les plus probables. Voici un exemple qui stocke le fuseau horaire actuel dans la session (la gestion d’erreur est totalement absente par simplicité). Ajoutez l’intergiciel suivant à [`MIDDLEWARE`](/fr/1.10/ref/settings/#std-setting-MIDDLEWARE): ``` import pytz from django.utils import timezone from django.utils.deprecation import MiddlewareMixin class TimezoneMiddleware(MiddlewareMixin): def process_request(self, request): tzname = request.session.get('django_timezone') if tzname: timezone.activate(pytz.timezone(tzname)) else: timezone.deactivate() ``` Créez une vue capable de définir le fuseau horaire actuel : ``` from django.shortcuts import redirect, render def set_timezone(request): if request.method == 'POST': request.session['django_timezone'] = request.POST['timezone'] return redirect('/') else: return render(request, 'template.html', {'timezones': pytz.common_timezones}) ``` Ajoutez un formulaire dans `template.html` dont la cible `POST` est cette vue : ```html+django {% load tz %} {% get_current_timezone as TIME_ZONE %}
{% csrf_token %}
``` ## Saisie de données avec fuseau horaire dans les formulaires Lorsque vous activez la prise en charge des fuseaux horaires, Django interprète les dates/heures saisies dans les formulaires dans le [fuseau horaire actuel](#default-current-time-zone) et place des objets `datetime` conscients dans Si le fuseau horaire actuel génère une exception pour les dates/heures qui n’existent pas ou qui sont ambiguës car elles se trouvent dans une transition d’heure d’été (les fuseaux horaires dans [pytz](http://pytz.sourceforge.net/) le font), ces dates/heures seront signalées comme non valables. ## Affichage de fuseaux horaires conscients dans les gabarits Lorsque vous activez la prise en charge des fuseaux horaires, Django convertit les objets `datetime` dans le [fuseau horaire actuel](#default-current-time-zone) au moment où ils sont affichés dans un gabarit. Ce comportement est très semblable à la [régionalisation des formats](/fr/1.10/topics/i18n/formatting/). > **Warning** > > Django ne convertit pas les objets `datetime` naïfs car ils peuvent être ambigus et parce que votre code ne doit jamais produire de tels objets naïfs lorsque la prise en charge des fuseaux horaires est activée. Cependant, vous pouvez forcer la conversion avec les filtres de gabarit décrits ci-dessous. La conversion en temps local n’est pas toujours adéquate, par exemple dans le cas où vous générez du contenu à destination d’autres ordinateurs. Les filtres et balises suivants, mis à disposition par la bibliothèque de balises de gabarit `tz`, permettent de contrôler les conversions de fuseaux horaires. ### Balises de gabarit #### `localtime` Active ou désactive la conversion d’objets `datetime` conscients dans le fuseau horaire actuel à l’intérieur du bloc contenu. Cette balise a exactement le même effet que le réglage [`USE_TZ`](/fr/1.10/ref/settings/#std-setting-USE_TZ) en ce qui concerne le moteur de gabarits. Elle permet un contrôle plus précis des endroits où la conversion se fait. Pour activer ou désactiver la conversion pour un bloc de gabarit, utilisez : ```html+django {% load tz %} {% localtime on %} {{ value }} {% endlocaltime %} {% localtime off %} {{ value }} {% endlocaltime %} ``` > **Note** > > La valeur de [`USE_TZ`](/fr/1.10/ref/settings/#std-setting-USE_TZ) n’est pas prise en compte à l’intérieur d’un bloc `{% localtime %}`. #### `timezone` Définit ou annule le fuseau horaire actuel dans le bloc contenu. Lorsque le fuseau horaire actuel est annulé, c’est le fuseau horaire par défaut qui s’applique. ```html+django {% load tz %} {% timezone "Europe/Paris" %} Paris time: {{ value }} {% endtimezone %} {% timezone None %} Server time: {{ value }} {% endtimezone %} ``` #### `get_current_timezone` Vous pouvez obtenir le nom du fuseau horaire actuel en utilisant la balise `get_current_timezone`: ```html+django {% get_current_timezone as TIME_ZONE %} ``` Une alternative possible est d’activer le processeur de contexte [`tz()`](/fr/1.10/ref/templates/api/#django.template.context_processors.tz) et d’utiliser la variable de contexte `TIME_ZONE`. ### Filtres de gabarit Ces filtres acceptent aussi bien des objets `datetime` conscients que naïfs. À des fins de conversion, ils partent du principe que les objets naïfs sont dans le fuseau horaire par défaut. Ils renvoient toujours des objets `datetime` conscients. #### `localtime` Force la conversion d’une valeur unique dans le fuseau horaire actuel. Par exemple : ```html+django {% load tz %} {{ value|localtime }} ``` #### `utc` Force la conversion d’une seule valeur en UTC. Par exemple : ```html+django {% load tz %} {{ value|utc }} ``` #### `timezone` Force la conversion d’une seule valeur dans un fuseau horaire arbitraire. Le paramètre doit être une instance d’une sous-classe de [`tzinfo`](https://docs.python.org/3/library/datetime.html#datetime.tzinfo) ou un nom de fuseau horaire. S’il s’agit d’un nom de fuseau horaire, [pytz](http://pytz.sourceforge.net/) est obligatoire. Par exemple : ```html+django {% load tz %} {{ value|timezone:"Europe/Paris" }} ``` ## Guide de migration Voici comment effectuer la migration d’un projet démarré avant que Django ne prenne en charge les fuseaux horaires. ### Base de données #### PostgreSQL Le moteur PostgreSQL stocke les dates/heures comme `timestamp with time zone`. En pratique, cela signifie qu’il convertit les objets `datetime` en UTC à partir du fuseau horaire de la connexion au moment du stockage, et à partir d’UTC vers le fuseau horaire de la connexion lors de la sélection. En conséquence, si vous utilisez PostgreSQL, vous pouvez librement passer de `USE_TZ = False` à `USE_TZ = True` et inversement. Le fuseau horaire de la connexion de la base de données sera défini respectivement à [`TIME_ZONE`](/fr/1.10/ref/settings/#std-setting-TIME_ZONE) et à `UTC`, ce qui fait que Django reçoit des dates/heures correctes dans tous les cas. Vous n’avez pas à convertir les données. #### Autres bases de données Les autres moteurs stockent les dates/heures sans information de fuseau horaire. Si vous passez de `USE_TZ = False` à `USE_TZ = True`, vous devez convertir vos données du temps local en UTC, ce qui n’est pas déterministe si votre temps local est sujet à l’heure d’été. ### Code La première étape est d’ajouter [`USE_TZ = True`](/fr/1.10/ref/settings/#std-setting-USE_TZ) à votre fichier de réglages et d’installer [pytz](http://pytz.sourceforge.net/) (si possible). À ce stade, tout devrait fonctionner en principe. Si vous créez des objets `datetime` naïfs dans votre code, Django les rend conscients en cas de besoin. Cependant, ces conversions peuvent échouer aux alentours des transitions d’heure d’été, ce qui signifie que vous n’obtenez pas encore tous les bénéfices de la prise en charge des fuseaux horaires. Il est également probable que vous rencontriez quelques problèmes car il est impossible de comparer une date/heure naïve avec une date/heure consciente. Comme Django vous donne maintenant des dates/heures conscientes, vous obtiendrez des exceptions chaque fois que vous comparez une date/heure provenant d’un modèle ou d’un formulaire avec une date/heure naïve que vous avez créée dans votre code. La seconde étape est donc de réviser votre code pour que chaque endroit où vous créer des objets `datetime`, ceux-ci soient conscients. Cela peut se faire progressivement. [`django.utils.timezone`](/fr/1.10/ref/utils/#module-django.utils.timezone) définit quelques utilitaires bien pratiques pour du code compatible : [`now()`](/fr/1.10/ref/utils/#django.utils.timezone.now), [`is_aware()`](/fr/1.10/ref/utils/#django.utils.timezone.is_aware), [`is_naive()`](/fr/1.10/ref/utils/#django.utils.timezone.is_naive), [`make_aware()`](/fr/1.10/ref/utils/#django.utils.timezone.make_aware) et [`make_naive()`](/fr/1.10/ref/utils/#django.utils.timezone.make_naive). Finalement, pour vous aider à trouver le code qui a besoin d’être mis à jour, Django émet un avertissement lorsque vous essayez d’enregistrer une date/heure naïve dans la base de données : ```python RuntimeWarning: DateTimeField ModelName.field_name received a naive datetime (2012-01-01 00:00:00) while time zone support is active. ``` Durant le développement, vous pouvez transformer ces avertissements en exceptions et obtenir une trace d’appel en ajoutant ce qui suit dans votre fichier de réglages : ```python import warnings warnings.filterwarnings( 'error', r"DateTimeField .* received a naive datetime", RuntimeWarning, r'django\.db\.models\.fields', ) ``` ### Instantanés Lors de la sérialisation d’une date/heure consciente, le décalage UTC est pris en compte, comme ceci : ```python "2011-09-01T13:20:30+03:00" ``` Pour une date/heure naïve, ce n’est évidemment pas le cas : ```python "2011-09-01T13:20:30" ``` Pour les modèles comportant des champs [`DateTimeField`](/fr/1.10/ref/models/fields/#django.db.models.DateTimeField), cette différence rend impossible l’écriture d’un instantané fonctionnant à la fois avec et sans prise en charge des fuseaux horaires. Les instantanés générés avec `USE_TZ = False` ou avant Django 1.4 utilisent le format « naïf ». Si votre projet contient de tels instantanés et que vous activez la prise en charge des fuseaux horaires, vous verrez des exceptions [`RuntimeWarning`](https://docs.python.org/3/library/exceptions.html#RuntimeWarning) lorsque vous les chargez. Pour vous débarrasser des ces avertissements, vous devez convertir vos instantanés au format « conscient ». Vous pouvez régénérer les instantanés avec [`loaddata`](/fr/1.10/ref/django-admin/#django-admin-loaddata), puis [`dumpdata`](/fr/1.10/ref/django-admin/#django-admin-dumpdata). Ou s’ils ne sont pas trop gros, vous pouvez simplement les modifier et ajouter le décalage UTC correspondant à votre [`TIME_ZONE`](/fr/1.10/ref/settings/#std-setting-TIME_ZONE) dans chaque objet `datetime` sérialisé. ## FAQ ### Configuration 1. **Je n’ai pas besoin de plusieurs fuseaux horaires. Dois-je activer la prise en charge des fuseaux horaires ?** Oui. Lorsque la prise en charge des fuseaux horaires est activée, Django utilise un modèle plus précis du temps local. Cela vous protège de bogues subtils et non reproductibles lors des transitions d’heure d’été (DST). À cet égard, les fuseaux horaires sont comparables à l’Unicode dans Python. Au début c’est difficile. Vous obtenez des erreurs de codage et de décodage. Puis vous apprenez comment ça marche. Et certains problèmes disparaissent, vous n’obtenez plus jamais d’affichage corrompu lorsque votre application reçoit du contenu non ASCII. Lorsque vous activez la prise en charge des fuseaux horaires, vous allez rencontrer certaines erreurs parce que vous utilisez des dates/heures naïves là où Django s’attend à des dates/heures conscientes. De telles erreurs apparaissent lors de l’exécution des tests et elles sont simples à corriger. Vous apprendrez rapidement comment éviter les opérations non valides. D’un autre côté, les bogues qui proviennent d’une non prise en charge des fuseaux horaires sont beaucoup plus durs à prévenir, à diagnostiquer et à corriger. Tout ce qui touche aux tâches planifiées ou à l’arithmétique des dates/heures est sujet à de subtils bogues qui ne vous affecteront qu’une ou deux fois par année. C’est pour ces raisons que la prise en charge des fuseaux horaires est activée par défaut dans les nouveaux projets, et vous devriez garder ce réglage pour autant que vous n’ayez pas une bonne raison de ne pas le faire. 2. **J’ai activé la prise en charge des fuseaux horaires. Suis-je tranquille ?** Peut-être. Vous êtes mieux protégé des bogues liés à l’heure d’été, mais il est toujours possible que vous vous trompiez en convertissant sans précaution des objets `datetime` naïfs en objets `datetime` conscients et vice-versa. Si votre application se connecte à d’autres systèmes, par exemple si elle interroge un service Web, prenez soin de bien définir les dates/heures. Pour les transmettre de manière fiable, leur représentation doit inclure le décalage UTC ou leur valeur doit être en UTC (ou les deux !). Finalement, notre système de calendrier contient des pièges intéressants pour les ordinateurs : ```python >>> import datetime >>> def one_year_before(value): # DON'T DO THAT! ... return value.replace(year=value.year - 1) >>> one_year_before(datetime.datetime(2012, 3, 1, 10, 0)) datetime.datetime(2011, 3, 1, 10, 0) >>> one_year_before(datetime.datetime(2012, 2, 29, 10, 0)) Traceback (most recent call last): ... ValueError: day is out of range for month ``` (Pour implémenter cette fonction, vous devez décider si 2012-02-29 moins une année est 2011-02-28 ou 2011-03-01, ce qui dépend de vos exigences métier) 3. **Dois-je installer pytz ?** Oui. La politique de Django est de ne pas exiger de dépendances externes, c’est pour cela que [pytz](http://pytz.sourceforge.net/) est facultatif. Cependant, il est beaucoup plus sûr de l’installer. Dès que vous activez la prise en charge des fuseaux horaires, Django a besoin d’une définition du fuseau horaire par défaut. Lorsque pytz est disponible, Django charge cette définition à partir de la [base de données tz](https://en.wikipedia.org/wiki/Tz_database). C’est la solution la plus précise. Sinon, il calcule les conversions en se basant sur la différence entre le temps local et le temps UTC tel que rapporté par le système d’exploitation. C’est moins fiable, en particulier durant les périodes de transitions d’heure d’été. De plus, si vous souhaitez gérer des utilisateurs dans plusieurs fuseaux horaires, pytz est la référence en ce qui concerne les définitions de fuseaux horaires. 4. **Comment interagir avec une base de données stockant les dates/heures en temps local ?** Définissez l’option [`TIME_ZONE`](/fr/1.10/ref/settings/#std-setting-DATABASE-TIME_ZONE) au fuseau horaire correspondant à cette base de données dans le réglage [`DATABASES`](/fr/1.10/ref/settings/#std-setting-DATABASES). C’est utile pour se connecter à une base de données qui ne gère pas les fuseaux horaires et qui n’est pas gérée par Django lorsque [`USE_TZ`](/fr/1.10/ref/settings/#std-setting-USE_TZ) vaut `True`. ### Dépannage 1. **Mon application plante avec** `TypeError: can't compare offset-naive` `and offset-aware datetimes` **, qu’est-ce que je fais faux ?** Reproduisons cette erreur en comparant des objets `datetime` naïf et conscient : ```python >>> import datetime >>> from django.utils import timezone >>> naive = datetime.datetime.utcnow() >>> aware = timezone.now() >>> naive == aware Traceback (most recent call last): ... TypeError: can't compare offset-naive and offset-aware datetimes ``` Si vous rencontrez cette erreur, il est très probable que votre code compare ces deux choses : - un objet `datetime` fourni par Django, par exemple une valeur lue à partir d’un champ de formulaire ou d’un champ de modèle. Comme vous avez activé la prise en charge des fuseaux horaires, cet objet est conscient. - un objet `datetime` généré dans votre code de manière naïve (sinon vous ne liriez pas ceci). Généralement, la solution correcte est de modifier votre code pour qu’il utilise plutôt un objet `datetime` conscient. Si vous écrivez une application réutilisable qui doit fonctionner indépendamment de la valeur de [`USE_TZ`](/fr/1.10/ref/settings/#std-setting-USE_TZ), il peut être utile d’appeler [`django.utils.timezone.now()`](/fr/1.10/ref/utils/#django.utils.timezone.now). Cette fonction renvoie la date et l’heure actuelle sous forme d’objet `datetime` naïf lorsque `USE_TZ = False` et sous forme d’objet `datetime` conscient lorsque `USE_TZ = True`. Vous pouvez y ajouter ou soustraire une valeur [`datetime.timedelta`](https://docs.python.org/3/library/datetime.html#datetime.timedelta) selon vos besoins. 2. **Je vois beaucoup de** `RuntimeWarning: DateTimeField received a naive datetime` `(YYYY-MM-DD HH:MM:SS)` `while time zone support is active` **, est-ce mauvais signe ?** Lorsque la prise en charge des fuseaux horaires est activée, la couche de base de données s’attend à ne recevoir que des objets `datetime` conscients de votre code. Cet avertissement se produit lorsqu’elle reçoit un objet `datetime` naïf. Cela indique que vous n’avez pas terminé de transformer votre code pour la prise en charge des fuseaux horaires. Veuillez vous référer au [guide de migration](#time-zones-migration-guide) pour des indications supplémentaires sur ce processus. Dans l’intervalle et par rétrocompatibilité, Django considère l’objet `datetime` comme se trouvant dans le fuseau horaire par défaut, ce qui correspond généralement à la réalité. 3. `now.date()` **est hier ! (ou demain)** Si vous avez toujours utilisé des objets `datetime` naïfs, vous pensez probablement pouvoir convertir un objet `datetime` en objet `date` en appelant sa méthode [`date()`](https://docs.python.org/3/library/datetime.html#datetime.datetime.date). Vous considérez également que [`date`](https://docs.python.org/3/library/datetime.html#datetime.date) est très semblable à [`datetime`](https://docs.python.org/3/library/datetime.html#datetime.datetime), avec moins de précision. Rien de cela n’est vrai dans un environnement conscient des fuseaux horaires : ```python >>> import datetime >>> import pytz >>> paris_tz = pytz.timezone("Europe/Paris") >>> new_york_tz = pytz.timezone("America/New_York") >>> paris = paris_tz.localize(datetime.datetime(2012, 3, 3, 1, 30)) # This is the correct way to convert between time zones with pytz. >>> new_york = new_york_tz.normalize(paris.astimezone(new_york_tz)) >>> paris == new_york, paris.date() == new_york.date() (True, False) >>> paris - new_york, paris.date() - new_york.date() (datetime.timedelta(0), datetime.timedelta(1)) >>> paris datetime.datetime(2012, 3, 3, 1, 30, tzinfo=) >>> new_york datetime.datetime(2012, 3, 2, 19, 30, tzinfo=) ``` Comme le montre cet exemple, le même objet `datetime` peut représenter une date différente selon le fuseau horaire dans lequel il est représenté. Mais le problème réel est plus fondamental. Un objet `datetime` représente un **point dans le temps**. C’est absolu et cela ne dépend de rien d’autre. Au contraire, une date est un **concept calendaire**. Il s’agit d’une période de temps dont les limites dépendent du fuseau horaire dans lequel la date est considérée. Comme vous pouvez le voir, ces deux concepts sont fondamentalement différents et la conversion d’un objet `datetime` en un objet `date` n’est pas une opération déterministe. Qu’est-ce que cela signifie en pratique ? Généralement, vous devriez éviter de convertir un objet [`datetime`](https://docs.python.org/3/library/datetime.html#datetime.datetime) en [`date`](https://docs.python.org/3/library/datetime.html#datetime.date). Par exemple, vous pouvez utiliser le filtre de gabarit [`date`](/fr/1.10/ref/templates/builtins/#std-templatefilter-date) pour n’afficher que la partie date d’un objet `datetime`. Ce filtre convertit l’objet `datetime` dans le fuseau horaire actuel avant de le mettre en forme, s’assurant ainsi que le résultat produit sera correct. Si vous avez réellement besoin d’effectuer vous-même la conversion, vous devez d’abord prendre soin de convertir l’objet `datetime` dans le fuseau horaire approprié. Il s’agit généralement du fuseau horaire actuel : ```python >>> from django.utils import timezone >>> timezone.activate(pytz.timezone("Asia/Singapore")) # For this example, we just set the time zone to Singapore, but here's how # you would obtain the current time zone in the general case. >>> current_tz = timezone.get_current_timezone() # Again, this is the correct way to convert between time zones with pytz. >>> local = current_tz.normalize(paris.astimezone(current_tz)) >>> local datetime.datetime(2012, 3, 3, 8, 30, tzinfo=) >>> local.date() datetime.date(2012, 3, 3) ``` 4. **J’obtiens une erreur** « `Are time zone definitions for your database and pytz installed?` » **pytz est installée, je suppose donc que le problème vient de ma base de données ?** Si vous utilisez MySQL, consultez la section [Définitions de fuseaux horaires](/fr/1.10/ref/databases/#mysql-time-zone-definitions) des notes MySQL pour plus d’instructions sur le chargement des définitions de fuseaux horaires. ### Utilisation 1. **J’ai une chaîne** `"2012-02-21 10:28:45"` **et je sais qu’elle est dans le fuseau horaire \*\* \`\` »Europe/Helsinki »\`\`. Comment puis-je la transformer en un objet \`\`datetime\`\` conscient ?** C’est exactement le rôle de [pytz](http://pytz.sourceforge.net/). ``` >>> from django.utils.dateparse import parse_datetime >>> naive = parse_datetime("2012-02-21 10:28:45") >>> import pytz >>> pytz.timezone("Europe/Helsinki").localize(naive, is_dst=None) datetime.datetime(2012, 2, 21, 10, 28, 45, tzinfo=) ``` Notez que `localize` est une extension de pytz à l’API [`tzinfo`](https://docs.python.org/3/library/datetime.html#datetime.tzinfo). Il peut être nécessaire d’intercepter les erreurs `pytz.InvalidTimeError`. La documentation de pytz contient [davantage d’exemples](http://pytz.sourceforge.net/#example-usage). Il est recommandé de la consulter avant d’essayer de manipuler des objets `datetime` conscients. 2. **Comment puis-je obtenir le temps local dans le fuseau horaire actuel ?** Et bien, la première question à se poser est : est-ce réellement nécessaire ? Le temps local ne doit être utilisé que lorsque l’on interagit avec des humains, et la couche des gabarits fournit des [filtres et des balises](#time-zones-in-templates) pour convertir des objets `datetime` dans le fuseau horaire de votre choix. De plus, Python sait comparer des objets `datetime` conscients, en prenant en compte les décalages UTC si nécessaire. C’est beaucoup plus simple (et potentiellement plus rapide) d’écrire tout le code des modèles et des vues en UTC. Ainsi, dans la plupart des cas, l’objet `datetime` en UTC renvoyé par [`django.utils.timezone.now()`](/fr/1.10/ref/utils/#django.utils.timezone.now) sera suffisant. Par souci d’exhaustivité, si vous devez vraiment obtenir le temps local dans le fuseau horaire actuel, voici comment vous pouvez l’obtenir : ```python >>> from django.utils import timezone >>> timezone.localtime(timezone.now()) datetime.datetime(2012, 3, 3, 20, 10, 53, 873365, tzinfo=) ``` Dans cet exemple, [pytz](http://pytz.sourceforge.net/) est installé et le fuseau horaire actuel est `"Europe/Paris"`. 3. **Comment puis-je voir tous les fuseaux horaires disponibles ?** [pytz](http://pytz.sourceforge.net/) fournit des [utilitaires](http://pytz.sourceforge.net/#helpers), y compris une liste des fuseaux horaires actuels et une liste de tous les fuseaux horaires disponibles, parmi lesquels se trouvent aussi certains qui n’ont qu’un intérêt historique.