La solution serait de conserver le temps atomique dans le timestamp, et de faire gérer les secondes intercalaires par zoneinfo et compagnie (C'est d'ailleurs ce que certains ont fait, mais attention : si ils installent ou activent NTP un jour, ils se retrouveront avec 2 secondes de décalage au lieu d'une seule)
Les applications bien conçues qui veulent une représentation linéaire du temps (Apache, MySQL..) travailleraient en timestamp, avec conversion UTC à l'affichage seulement. Celles qui travaillent dans le futur avec du temps humain (ce crédit doit être remboursé le 1er Mai 2030 à 00:00 heure de Paris) stockeraient tout en UTC.
# Défaillant par conception
Posté par Deuterium . En réponse au journal Leap second. Évalué à 7.
L'ajout d'une seconde intercalaire modifie le timestamp unix, et non pas seulement la représentation textuelle humaine de l'heure. Sur vos systèmes, il y a donc bien eu une seconde (informatique) qui a duré deux secondes (physiques), et ce mondialement. Le timestamp est tout sauf le nombre de secondes écoulées depuis epoch.
La solution serait de conserver le temps atomique dans le timestamp, et de faire gérer les secondes intercalaires par zoneinfo et compagnie (C'est d'ailleurs ce que certains ont fait, mais attention : si ils installent ou activent NTP un jour, ils se retrouveront avec 2 secondes de décalage au lieu d'une seule)
Les applications bien conçues qui veulent une représentation linéaire du temps (Apache, MySQL..) travailleraient en timestamp, avec conversion UTC à l'affichage seulement. Celles qui travaillent dans le futur avec du temps humain (ce crédit doit être remboursé le 1er Mai 2030 à 00:00 heure de Paris) stockeraient tout en UTC.