Sondage Ce qui m’agace le plus lorsque je manipule des dates

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
9
6
mai
2019

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

La liste des options proposées est volontairement limitée : tout l’intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées ou de l’impossibilité de choisir plusieurs réponses. 76,78 % des personnes sondées estiment que ces sondages sont ineptes.

  • # Parce qu'il fallait la faire...

    Posté par  . Évalué à 10.

    Ce qui m'agace le plus lorsque je manipule des dates

    De ne pas avoir le choix (dans la date). Vous pouvez maintenant reprendre vos histoires de bits.

  • # Gloire à l'ISO

    Posté par  (site web personnel) . É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  (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  (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  . Évalué à 7.

    .

  • # Les horloges de PC à l'heure UTC

    Posté par  (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 ou date --utc et ne confondent pas avec date !
    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  . É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  . Évalué à 0.

    timestamp -> local time
    local time -> timestamp
    timestamp -> UTC
    UTC -> timestamp

  • # La multiplication des horloges

    Posté par  (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  . Évalué à 2.

    … les dates, justement T_T

  • # en decimal

    Posté par  . É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  . É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  . É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  . É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  . É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.

    • [^] # Re: les mélanges

      Posté par  . É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  . É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…).

  • # Les fuseaux horaires ambiguës ou même manquant.

    Posté par  . É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  . É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. 

      # tz  <TIME SPECIFICATION>  
#
# Display the specified time in multiple timezones (default is "now").
#
# Timezones are sorted by their UTC offsets.
#
# Timezones with the same UTC offset than the current timezone
# are marked with '*'
#
# However, they are marked with '?' instead if the current time
# and the specified time are not equal which usually indicates
# a summer/winter time change.    
#
# Examples:  (see 'info date' for more)
#
#   tz                    : for current time (or "now")  
#   tz 14:00              : for 14:00 today in the current timezone
#   tz 14:00+4            : for 14:00 today in UTC+4 
#   tz tomorrow 2pm PST   : for 14:00 tomorrow in Pacific Standard Time 
#   tz 2pm July 3 CEST    : for Friday July 3 14:00 2015 in Central European Summer Time 
#
# Remark: Not all symbolic timezone names work as expected.
#         First because some of them are only valid during parts of the year (e.g CET
#         vs CEST in Central Europe) and also because some names are ambiguous
#         (e.g. CST may refer to Central Standard Time in the US and to China Standard Time
#         in Chine). Using UTC or GMT relative timezones is usually safer.
#
# http://www.timeanddate.com/time/map/
#
tz () {
    local FMT A D T tz M UTC0 UTC1 LOCATIONS 
    D="$*"
    # Output format (see man 1 date)
    FMT="%H:%M %_4Z (UTC%:z) %a %b %d"
    # FMT="%c %Z (UTC%:z)"
    [ -n "$D" ] || D=now    
    T=$(date -d "$D" +%s) || return
    # Add here your preferred locations (as given by tzselect)
    LOCATIONS+=" America/Los_Angeles"   # PST/PDT
    #LOCATIONS+=" America/Denver"        # MST/MDT
    LOCATIONS+=" America/Chicago"       # CST/CDT
    LOCATIONS+=" America/New_York"      # EST/EDT
    LOCATIONS+=" Europe/London"         # GMT/BST
    LOCATIONS+=" Europe/Paris"          # CET/CEST 
    #LOCATIONS+=" Asia/Shanghai"         # CST (China Standard Time)
    LOCATIONS+=" Asia/Tokyo"            # JST 
    #LOCATIONS+=" Australia/Melbourne"   # AEDT/AEST
    #LOCATIONS+=" Australia/Adelaide"    # ACDT/ACST
    # Get current timezone now (in $UTC0) and at requested time (in $UTC1)
    # They may be different because of summer/winter time changes. 
    UTC0=$(LC_ALL=C  date -d "now" +"%z")
    UTC1=$(LC_ALL=C  date -d "@$T" +"%z")
    for tz in $LOCATIONS ; do
        # UTC2 is the UTC timezone of $tz at the given time 
        UTC2=$(LC_ALL=C TZ="$tz" date -d "@$T" +"%z")
        if [ "$UTC1" == "$UTC2" ] ; then
            if [ "$UTC0" == "$UTC1" ] ; then
                M="*"  # This is consistent with current timezone.
            else
                M="?"  # Also but probably with a summer/winter time change.
            fi
        else
            M=" "
        fi
        A=$(LC_ALL=C TZ="$tz" date -d "@$T" +"$FMT")
        # Prefix each output line with its numeric timezone. 
        # That prefix will we removed after sorting.
        printf "%s %c%-20s %s\n" "$UTC2" "$M" "$tz" "$A"
    done | sort -n | cut -c 7-
}

      • [^] # Re: Les fuseaux horaires ambiguës ou même manquant.

        Posté par  . Évalué à 5.

        En Python (fait très rapidement) :

        import sys
import pendulum

if not 1 < len(sys.argv) <= 3:
    print('Usage: {} <date time> [timezone]'.format(sys.argv[0]))
    sys.exit(1)

try:
    datetime = pendulum.parse(sys.argv[1])
except pendulum.parsing.ParserError as e:
    print(e)
    sys.exit(1)

try:
    timezone = pendulum.timezone(sys.argv[2])
except IndexError:
    timezone = pendulum.UTC
except pendulum.tz.zoneinfo.exceptions.InvalidTimezone as e:
    print(e)
    sys.exit(1)

print(datetime.astimezone(timezone))

  • # Passer au format Asiatique

    Posté par  . É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).

  • # Time, Clock, and Calendar Programming In C

    Posté par  (site web personnel, 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.