C'est une question importante et étonnamment difficile. La vérité est qu'il n'y a pas de norme complètement satisfaisante pour la persistance du temps. Par exemple, la norme SQL et le format ISO (ISO 8601) ne sont clairement pas suffisants.
Du point de vue conceptuel, on traite généralement de deux types de données de date et d'heure, et il est commode de les distinguer (les normes ci-dessus ne le font pas): " heure physique " et " heure civile ".
Un instant "physique" du temps est un point de la chronologie universelle continue avec lequel la physique traite (en ignorant la relativité, bien sûr). Ce concept peut être adéquatement codé en UTC, par exemple (si vous pouvez ignorer les secondes intercalaires).
Un temps "civil" est une spécification datetime qui suit les normes civiles: un point de temps ici est entièrement spécifié par un ensemble de champs datetime (Y, M, D, H, MM, S, FS) plus un TZ (spécification de fuseau horaire) (également un "calendrier", en fait; mais supposons que nous limitons la discussion au calendrier grégorien). Un fuseau horaire et un calendrier permettent conjointement (en principe) de mapper d'une représentation à l'autre. Mais les instants temporels civils et physiques sont des types de magnitudes fondamentalement différents, et ils devraient être séparés conceptuellement et traités différemment (une analogie: des tableaux d'octets et des chaînes de caractères).
La question est confuse parce que nous parlons de ces types d'événements de manière interchangeable et parce que l'époque civile est sujette à des changements politiques. Le problème (et la nécessité de distinguer ces concepts) devient plus évident pour les événements futurs. Exemple (tiré de ma discussion ici .
John enregistre dans son calendrier un rappel pour un événement à l'heure
2019-Jul-27, 10:30:00
, TZ = Chile/Santiago
, (qui a décalé GMT-4, donc cela correspond à UTC 2019-Jul-27 14:30:00
). Mais un jour à l'avenir, le pays décide de changer la compensation TZ en GMT-5.
Maintenant, quand le jour viendra ... si ce rappel se déclenche à
A) 2019-Jul-27 10:30:00 Chile/Santiago
= UTC time 2019-Jul-27 15:30:00
?
ou
B) 2019-Jul-27 9:30:00 Chile/Santiago
= UTC time 2019-Jul-27 14:30:00
?
Il n'y a pas de bonne réponse, à moins que l'on ne sache ce que Jean voulait dire conceptuellement quand il a dit au calendrier "Veuillez me téléphoner à 2019-Jul-27, 10:30:00
TZ=Chile/Santiago
".
Voulait-il dire un «rendez-vous civil» («quand les horloges de ma ville indiquent 10 h 30»)? Dans ce cas, A) est la bonne réponse.
Ou voulait-il dire un "instant physique du temps", un point dans la ligne continue du temps de notre univers, disons, "quand la prochaine éclipse solaire se produira". Dans ce cas, la réponse B) est la bonne.
Quelques API Date / Heure obtiennent cette distinction: parmi elles, Jodatime , qui est le fondement de la prochaine (troisième!) API Java DateTime (JSR 310).
GETDATE()
sur SQL sera UTC (comme le seraDateTime.Now
). Et le serveur ne sera affecté par aucune sorte de modifications DST automatiques.