Fun avec les TZ

Bonjour à tous, il y a un truc que je n'arrive pas à m'expliquer.

J'ai un nouveau capteur qui me génère de la donnée temporelle.
Mais j'ai un décalage dans l'interprétation de postgresql que je trouve plus que bizarre.

La première ligne est la valeur reçue dans le csv.

select
'Sat Oct 21 15:01:06 GMT+02:00 2017'::timestamptz,
'Sat Oct 21 15:01:06 GMT+02:00 2017'::timestamp,
'Sat Oct 21 15:01:06 +02:00 2017'::timestamptz;

2017-10-21 19:01:06+02
2017-10-21 15:01:06
2017-10-21 15:01:06+02

On voit bien que l'interprétation de GMT+2 donne un résultat abhérant
de 19h00 pour un 15h00 CEST (c'est genre +2+2).

Moteur de recherche et documentation n'ont pas réussi à me fournir une explication
probante. Je peux toujours sedizé les CSV, mais bon tout traitement inutile est toujours
le bien venu.

Mon serveur 9.6.4 indique
show timezone = posixrules (Le linux pointe sur Europe/Zurich, CEST)

L'objectif serait d'obtenir un stockage fiable si possible UTC.

Merci d'avance si quelqu'un à une idée.

--

Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch
Bareos Partner, openSUSE Member, fsfe fellowship
GPG KEY : D5C9B751C4653227
irc: tigerfoot

On 2017-10-21 13:05, Bruno Friedmann wrote:
> Mon serveur 9.6.4 indique
> show timezone = posixrules (Le linux pointe sur Europe/Zurich, CEST)
>
> L'objectif serait d'obtenir un stockage fiable si possible UTC.

blah=# select now();
now
-------------------------------
2017-10-21 14:03:14.919573-06
(1 row)

Time: 0.946 ms
blah=# set session time zone utc;
SET
Time: 0.596 ms
blah=# select now();
now
-------------------------------
2017-10-21 20:03:27.327525+00
(1 row)

Valide que pendant la session courante.

--
https://yves.zioup.com
gpg: 4096R/32B0F416

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Bruno Friedmann wrote:

> 'Sat Oct 21 15:01:06 GMT+02:00 2017'::timestamptz,
> 'Sat Oct 21 15:01:06 GMT+02:00 2017'::timestamp,
> 'Sat Oct 21 15:01:06 +02:00 2017'::timestamptz;
>
> 2017-10-21 19:01:06+02
> 2017-10-21 15:01:06
> 2017-10-21 15:01:06+02
>
> On voit bien que l'interprétation de GMT+2 donne un résultat
> abhérant de 19h00 pour un 15h00 CEST (c'est genre +2+2).

En fait le résultat est juste parce que pour la norme POSIX,
GMT+02:00 c'est 2 heures à l'ouest du méridien de Greenwich,
au contraire de l'expression de la 3eme colonne qui fait référence
à la norme ISO-8601, orientée dans l'autre sens (2 heures à l'est
de Greenwich), celui qui est utilisé le plus souvent.
Quand on est 2h à l'est de GMT, par exemple l'heure d'été française,
on est bien décalé de 4h par rapport à un fuseau qui serait 2h à
l'ouest de GMT.

Cf la doc:
https://doc.postgresql.fr/10/datatype-datetime.html

" Un autre problème à conserver en tête est que, pour les noms des
fuseaux horaires POSIX, les décalages positifs sont utilisés pour
les emplacements situés à l'ouest de Greenwich. Partout ailleurs,
PostgreSQL™ suit la convention ISO-8601 pour qui les décalages
positifs de fuseaux horaires concernent l'est de Greenwich"

La même confusion existe en-dehors de Postgres,
par exemple sur un système Ubuntu, avec la commande date
du système et une conf locale sur Europe/Paris:

$ date
dimanche 22 octobre 2017, 09:23:06 (UTC+0200)

$ TZ=GMT+2 date
dimanche 22 octobre 2017, 05:23:06 (UTC-0200)

parce que TZ suit POSIX alors que l'affichage par défaut
de la date suit l'autre convention.

--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Merci Daniel et Yves.

Ce que je constate, c'est que dans tous les cas la sonde n'écrit pas une date correcte, du
coup sed ou rewritte de la donnée brute.

Soit en +02:00 seul (suppression de GMT) soit GMT-02:00
Le second me plaît mieux dans le sens iso-8601 simplifiant la documentation
des normes utilisées.

Bon dimanche.

--

Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch
Bareos Partner, openSUSE Member, fsfe fellowship
GPG KEY : D5C9B751C4653227
irc: tigerfoot

Le 22 octobre 2017 à 12:11, Bruno Friedmann <bruno(at)ioda-net(dot)ch> a écrit :

> Merci Daniel et Yves.
>
>
>
> Ce que je constate, c'est que dans tous les cas la sonde n'écrit pas une
> date correcte, du coup sed ou rewritte de la donnée brute.
>

juste pour compléter l'excellente réponse de Daniel (je ne vois pas trop
l'intérêt d'un sed/rewrite, voir conversion possible vers timestamp
ci-dessous si vraiment cela semble nécessaire):

select
'Sat Oct 21 15:01:06 GMT+02:00 2017'::timestamptz at time zone
'America/Miquelon',
'Sat Oct 21 15:01:06 GMT+02:00 2017'::timestamptz at time zone 'PMDT',
'Sat Oct 21 15:01:06 GMT+02:00 2017'::timestamptz at time zone 'UTC +2',
'Sat Oct 21 15:01:06 GMT+02:00 2017'::timestamp,
'Sat Oct 21 15:01:06 +02:00 2017'::timestamptz;
-[ RECORD 1 ]-----------------------
timezone | 2017-10-21 15:01:06
timezone | 2017-10-21 15:01:06
timezone | 2017-10-21 15:01:06
timestamp | 2017-10-21 15:01:06
timestamptz | 2017-10-21 15:01:06+02

# set timezone TO 'America/Miquelon';
# select 'Sat Oct 21 15:01:06 GMT+02:00 2017'::timestamptz;
-[ RECORD 1 ]-----------------------
timestamptz | 2017-10-21 15:01:06-02

Il faut bien distinguer la date d'affichage, la date de stockage et la date
en entrée.
Est-ce vraiment la sonde qui est incorrecte ?

>
> Soit en +02:00 seul (suppression de GMT) soit GMT-02:00
>
> Le second me plaît mieux dans le sens iso-8601 simplifiant la documentation
>
> des normes utilisées.
>
>
>
> Bon dimanche.
>
>
>
> --
>
>
>
> Bruno Friedmann
>
> Ioda-Net Sàrl www.ioda-net.ch
>
> Bareos Partner, openSUSE Member, fsfe fellowship
>
> GPG KEY : D5C9B751C4653227
>
> irc: tigerfoot
>
>
>
>
>

--

--
Cédric Villemain +33 (0)6 20 30 22 52http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation