Depuis le bogue de l’an 2000, le grand public sait que la manipulation des dates peut être un vaste bricolage, et heureusement les mauvaises pratiques de l’informatique de gestion des années 1970 ne devraient plus exister. Cependant, il arrive que l’on soit obligé de manipuler des dates dont nous n’avons pas choisi le format, ce qui peut s’avérer agaçant…
-
le mois avant le jour (mm/dd/yyyy) :
839(59.0 %)
-
l’année sur deux caractères :
81(5.7 %)
-
l’unix_time en 32 bits :
62(4.4 %)
-
le (non‐)choix du fuseau horaire :
153(10.8 %)
-
la date en toutes lettres :
167(11.8 %)
-
les fonctions de tri non prévues :
119(8.4 %)
Total : 1421 votes
# Parce qu'il fallait la faire...
Posté par nico4nicolas . Évalué à 10.
De ne pas avoir le choix (dans la date). Vous pouvez maintenant reprendre vos histoires de bits.
[^] # Re: Parce qu'il fallait la faire...
Posté par PegaseYa . Évalué à 7.
Il faut que je pense à embaucher des femmes qui compilent le C.
[^] # Re: Parce qu'il fallait la faire...
Posté par jigso . Évalué à 5.
Attention au débordement de tampon avec les strings.
[^] # Re: Parce qu'il fallait la faire...
Posté par urschuca . Évalué à 2.
Le spam c'est pervers.
[^] # Re: Parce qu'il fallait la faire...
Posté par kna . Évalué à 5.
Il faut bien mettre le string dans l'array
# Gloire à l'ISO
Posté par Wawet76 . Évalué à 10.
Je suis agacé dès qu'une date à manipuler n'est pas en ISO 8601 en fait.
[^] # Re: Gloire à l'ISO
Posté par Pol' uX (site web personnel) . Évalué à 7.
Ya un xkcd pour ça : https://xkcd.com/1179/
Adhérer à l'April, ça vous tente ?
[^] # Re: Gloire à l'ISO
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 3.
ISO 8601, comme toutes les normes ISO, permet de tas de variantes et vous seriez bien embêté·e·s s'il fallait écrire du code pour gérer toutes les possibilités d'ISO 8601. Notamment, contrairement à une légende répandue, ISO 8601 ne garantit pas que le tri alphabétique soit également un tri chronologique.(Si quelqu'un ici a déjà lu la norme ISO 8601, qu'ielle lève la main.)
La bonne solution pour les dates est celle du RFC 3339.
# [] manipuler des dates
Posté par Thomas Douillard . Évalué à 7.
.
# Les horloges de PC à l'heure UTC
Posté par Pierre Jarillon (site web personnel) . Évalué à 5. Dernière modification le 06 mai 2019 à 15:06.
Il m'arrive de trouver des PC dont l'heure (BIOS) est à l'heure locale. Ça m'énerve.
C'est tellement plus simple de mettre l'heure UTC (Coordinated Universal Time ) ou Temps universel coordonné. Ainsi, l'heure système est indépendante des fuseaux horaires et des heures d'été et l'heure affichée est l'heure locale calculée à partir d'elle.
Les gens civilisés savent faire
date -u
oudate --utc
et ne confondent pas avecdate
!Le machines bien fichues mesurent les dates à partir du début de 1970, le zéro de l’ère informatique.
Pour terminer, j'ai une pensée pour NTP qui permet de maintenir nos ordinateurs à l'heure.
[^] # Re: Les horloges de PC à l'heure UTC
Posté par feth . Évalué à 3.
NTP qui permet de tricher avec l'heure qu'il est, et de manière différente selon que tu utilises google ou amazon (leap smear…).
Ce qu'il nous faudrait, c'est qu'on abandonne la synchro sur l'heure astronomique pour les machines, et qu'on adopte TAI une bonne fois, plus l'heure solaire locale pour les horaires d'ouverture.
# timestamp <-> local time, timestamp <-> UTC
Posté par David . Évalué à 0.
timestamp -> local time
local time -> timestamp
timestamp -> UTC
UTC -> timestamp
# La multiplication des horloges
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
L'hyperviseur a son horloge et il est synchronisé NTP. Dessus on fait tourner des machines virtuelles, dont certaines auront des ntpd. Autant je me dis que c'est logique si je veux une machine virtuelle où le temps s'écoule plus vite ou plus lentement ou à l'envers ou en pas à pas, autant dans le cas général, ça me semble toujours du gâchis.
# Ben…
Posté par Ruminant . Évalué à 2.
… les dates, justement T_T
# en decimal
Posté par Anonyme . Évalué à 2.
car c'est plus pratique :'(
il s'agit plus de la gestion de l'heure que de la date dans mon cas.
# dates en bdd
Posté par Maxzor . Évalué à 1.
Les dates dans ma base de données pourrie (un logiciel d'entrepôt) qui sont sur 4 ****** de champs, en mode années 60 : siècle(20) - année(19) - mois(05) - jour.
# mauvaises, ces dattes
Posté par WrathOfThePixel . Évalué à 6.
Je manipules pas les dattes moi, c'est dégueux. Il y a des gens qui les mangent après.
# les mélanges
Posté par Albert_ . Évalué à 6.
Les données avec des dates en mm/dd/yyyy et plus tard en dd/mm/yyyy…
[^] # Re: les mélanges
Posté par abriotde (site web personnel, Mastodon) . Évalué à 4.
exact : Les applis française anglicisé avec une date sur 3 traduites en anglais, une date sur 3 en français le reste au format base de donné parfois à l'IHM. En fait la non cohérence dans les applications.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: les mélanges
Posté par etbim . Évalué à 1.
Je vous recommande également les dates en format UTC et en heure locales (donc tantôt heure d'été et heure d'hiver) dans un même fichier, sans indications ni traces lors des changements…
(Trop) récurent dans les ENR (merci à leurs SCADA pourris).
# Les 2 principaux bugs : les dates et l'encodage des caractère.
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2.
Ce qui est foncièrement agaçant c'est la non-standardisation et les idées tordues qui peuvent exister. D"jà que le temps est complexe historiquement (Le nombre de jours dans la semaine n'est pas le même que le nombre de semaine dans l'année etc…) mais en plus des politiques ont des idées tordues comme introduire des changement d'heure (Ce qu'il fait qu'au moment du changement d'heure une heure disparaît ou apparaît avec le même nom (à minuit et demi ancienne heure est une heure après minuit et demi nouvel heure…)). Et je ne vous parle pas des changement d'heure décidé au dernier moment en avec le ramadan en fonction de l'humeur de l'Imam du pays.
Et pour finir le pire c'est qu'il est très délicat de tester le comportement d'un programme pour tous les cas (changement d'heure, seconde intercalaire…).
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Les 2 principaux bugs : les dates et l'encodage des caractère.
Posté par nico4nicolas . Évalué à 5. Dernière modification le 07 mai 2019 à 14:45.
Je pensais que tu allais parler des années bissextiles une fois sur quatre… sauf tous les 100 ans où l'année qui devait être bissextile ne l'est pas… sauf tous les 400 ans où l'année qui devait être bissextile et qui ne l'est pas l'est quand même. J'ai souvenir d'avoir voulu installer un logiciel (Microsoft) le 29 février 2012 et le logiciel m'avait gentiment répondu que la date n'était pas valide.
Cela étant, je crois comprendre que la question du sondage porte sur la représentation des dates et non pas le système de datation.
[^] # Re: Les 2 principaux bugs : les dates et l'encodage des caractère.
Posté par SChauveau . Évalué à 3.
Je ne compte plus le nombre de fois ou j'ai loupé une conf-call parce qu'aux USA il font le changement été-hivers 1 ou 2 semaines avec nous.
[^] # Re: Les 2 principaux bugs : les dates et l'encodage des caractère.
Posté par SChauveau . Évalué à 3.
Il faut bien entendu lire "… 1 ou 2 semaines avant nous"
# Les fuseaux horaires ambiguës ou même manquant.
Posté par SChauveau . Évalué à 1.
Cela n'est arrivé de nombreuses fois avec invitations pour des conf-calls avec des américains (donc au moins 4 fuseaux horaires possibles). Du genre "Let's have a call at 10am next monday".
Un cas réel encore plus pernicieux: Le titre de l'email auto-généré par le calendrier dit "10am PDT Dec 5" donc la côte Ouest US en heures d'été mais on est en hivers donc cela devrait être PST. Et pour ne rien arranger, le gars à voulu être sympa et a aussi donné l'heure pour 'Paris' mais cela ne correspond ni à 10am PDT ni à 10am PST.
[^] # Re: Les fuseaux horaires ambiguës ou même manquant.
Posté par SChauveau . Évalué à 4.
D'ailleurs, si cela peux intéresser quelqu'un, voici la petite fonction Bash que j'utilisai pour convertir une date dans les fuseaux horaires utiles pour mon boulot.
[^] # Re: Les fuseaux horaires ambiguës ou même manquant.
Posté par Anonyme . Évalué à 5.
En Python (fait très rapidement) :
# Passer au format Asiatique
Posté par Shunesburg69 . Évalué à 0. Dernière modification le 08 mai 2019 à 15:00.
Perso, je trouve le format Asiatique plus logique et pratique :
AAAA-MM-JJ
Ce qui permet d'ailleurs de ranger les dates par le tri alphanumérique.
Pour ce qui est de l'heure de base, on devrait tout simplement supprimer les heures locales et tous se mettre à l'heure de Greenwich (UTC), et supprimer les heure d'été/hivers sur les OS (ce qui n'empêche pas de mettre une horloge local en plus, pour savoir l'heure qu'il est).
[^] # Re: Passer au format Asiatique
Posté par Pierre Jarillon (site web personnel) . Évalué à 10. Dernière modification le 08 mai 2019 à 17:53.
Ce n'est pas un format spécifiquement asiatique mais ce qui est recommandé par ISO_8601.
La page Wikipédia est bien faite, sa connaissance devrait être obligatoire dès l'école primaire !
# Time, Clock, and Calendar Programming In C
Posté par Tonton Th (Mastodon) . Évalué à 3.
À chaque fois que j'entend un troll sur les dates en informatique, je ne peux m'empécher de citer cette page :)
The C/Unix time- and date-handling API is a confusing jungle full of the corpses of failed experiments and various other traps for the unwary, many of them resulting from design decisions that may have been defensible when the originals were written but appear at best puzzling today.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.