Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
Ce RFC modifie
légèrement le format des estampilles temporelles du RFC 3339, changeant à la marge une définition et, surtout,
permettant d'y attacher des informations supplémentaires.
Le RFC 3339 décrit un des formats
d'estampilles temporelles possibles sur l'Internet (car,
malheureusement, toutes les normes Internet ne l'utilisent pas). Un
exemple, sur Unix :
% date --rfc-3339=seconds
2024-04-29 06:22:33+00:00
Le format du RFC 3339 est du type « YYYY-MM-DD
HH:MM:SS » avec, à la fin, ajout d'une information sur le décalage
avec le temps de référence (on verra que notre nouveau
RFC 9557 change un peu cette dernière information). Un
format gros boutien, donc, qui permet
notamment de trier les dates-et-heures uniquement en suivant
l'ordre
lexicographique des caractères.
Mais certaines applications voudraient en savoir plus, et ajouter
à ce format des détails. D'ailleurs, c'est déjà fait dans des
solutions non normalisées, comme le
format de Java, très populaire, qui permet des estampilles
comme 2011-12-03T10:15:30+01:00[Europe/Paris]
(fuseau horaire, ajouté après la date au
format du RFC 3339 ; lisez le RFC 6557 pour en savoir davantage sur les fuseaux
horaires).
Ce nouveau RFC
prévoit donc une extension optionnelle (les dates-et-heures qui
suivaient le format de l'ancien RFC restent parfaitement valdies),
compatible avec celle de Java, et généraliste (on pourra indiquer
autre chose que le fuseau horaire). Ce format étendu est baptisé
IXDTF pour Internet Extended Date/Time
Format. En revanche, le nouveau format ne gère pas des cas
compliqués (la gestion du temps en informatique est toujours
compliquée) comme les dates futures lorque la définition du fuseau
horaire changera, par exemple en supprimant l'heure
d'été, ou des échelles de temps différentes, comme
TAI (le
format IXDTF ne marche que pour l'échelle d'UTC).
Donc, concrètement, notre RFC commence par changer un peu la
définition du décalage à la fin des estampilles. Dans le RFC 3339, il y avait trois cas subtilement
différents pour une estampille
indiquant l'absence de décalage :
- Une lettre Z indiquait qu'on utilisait UTC comme
référence,
- Un
+00:00 indiquait qu'on utilisait UTC
comme référence (identique au cas précédent),
- Un
-00:00 indiquait qu'on n'avait
aucune idée sur la référence (typiquement parce qu'on voudrait
connaitre l'heure locale mais qu'on ne la
connait pas).
(Au passage, si vous ne connaissiez pas ces trois cas et leurs
différences, ne vous inquiétez pas, vous n'étiez pas seul·e.) Notre
RFC change cela (section 2) en décidant que Z est désormais synonyme
de
-00:00 plutôt que de
+00:00, un changement qui aura sans doute peu
d'importance en pratique.
L'autre nouveauté de ce RFC 9557 est plus marquante,
c'est le format étendu IXDTF (section 3). Il consiste à ajouter à la
fin de l'estampille une série (facultative) de couples {clé,
valeur}, entre crochets. Si la clé est
absente, c'est que la valeur est un fuseau horaire, suivant la
syntaxe de la base
TZ. Voici un exemple :
2022-07-08T12:14:37+02:00[Europe/Paris][u-ca=hebrew]
Cet exemple indique que le fuseau horaire était celui de
Paris (cf. le
format de
ces noms de fuseaux) et que le calendrier préféré (clé
u-ca), pour afficher cette date, serait le
calendrier hébreu (ce qui indiquera 9 Tammouz
5782, sauf erreur).
Un point d'exclamation avant la clé
indiquerait que la clé doit être comprise par le lecteur, sinon, il
faut qu'il ignore l'estampille temporelle (la plupart du temps,
l'application peut ignorer les clés et leurs valeurs). Un
trait bas indique une clé expérimentale, non
officiellement enregistrée.
Car notre RFC crée aussi un registre
des clés. Pour l'instant, il ne compte qu'une seule clé,
u-ca, pour indiquer le calendrier préféré. Pour
enregistrer une nouvelle clé, il faut une spécification écrite
(cf. RFC 8126), mais il y a aussi des
enregistrements temporaires, plus légers.
Et on termine par un petit mot sur la sécurité (section 7). Le
RFC rappelle que plus on donne d'informations, plus on risque d'en
donner trop. Ainsi, l'indication du calendrier préféré peut indiquer
une origine ethnique ou religieuse, qui peut être considérée comme
privée, surtout s'il y a des risques d'attaques racistes.
