Discussion:ISO 8601

Bouts de code (2006-2007)

exemple en asp A Bergamini, Fonction Semaine Calcul le numéro de semaine d'une date

Function Semaine(StrDate )
Jeudi=StrDate+4-weekday(StrDate,2)
Janvier4=Cdate("04/01/"&Year(Jeudi))
Lundi4=Janvier4-Weekday(Janvier4,2)
NbJ=Jeudi-Lundi4
Semaine=Right("0"&round(NbJ/7+.5),2)
End Function

(ajouté par une IP, déplacé en page de discussion par / DC2 • )

Code en VisualBasic.Net 1 et 2 basé sur le source fourni en ASP

 Function NumeroSemaine(ByVal dtDate As Date) As Int32
   ' Retourne le numéro de la semaine conformement à la norme ISO8601
   Dim iNumSemaine As Int32
   Dim dtJeudi As Date = DateAdd(DateInterval.Day, 4, dtDate)
   Dim iJourSemaine As Int32 = JourSemaine(dtDate)
   dtJeudi = DateAdd(DateInterval.Day, -iJourSemaine, dtJeudi)
   Dim dtJanvier4 As Date = New Date(dtJeudi.Year, 1, 4)
   Dim dtLundi4 As Date = DateAdd(DateInterval.Day, -JourSemaine(dtJanvier4), dtJanvier4)
   Dim iNbJour As Int32 = DateDiff(DateInterval.Day, dtLundi4, dtJeudi)
   iNumSemaine = Right("0" & Math.Round(iNbJour / 7 + 0.5), 2)
   Return iNumSemaine
 End Function
 Private Function JourSemaine(ByVal dtDate As Date) As Int32
   ' Retourne le jour de la semaine du lundi (1) au dimanche (7)
   Dim iJourSemaine As Int32 = dtDate.DayOfWeek
   If iJourSemaine = 0 Then iJourSemaine = 7
   Return iJourSemaine
 End Function

Code en VisualBasic.Net

Nous proposons une autre fonction de calcul, basée sur une expression simplifiée de l'algorithme de référence. La date courante est rapportée au jeudi de la semaine courante. Par exemple, pour un lundi, on se rapporte au jeudi suivant ; pour un dimanche, on se rapporte au jeudi précédent. Le numéro de la semaine courante est égal au nombre de semaines complètes entre ce jeudi courant et le début de l'année (de ce jeudi-là) + 1. Autrement dit, cela correspond au numéro de jour de l'année de ce jeudi courant divisé par 7 (le nombre de jours dans une semaine)(division arrondie à l'entier inférieur) et plus 1 (premier numéro de semaine dans l'année).

 Public Function Semaine(ByVal D As Date) As Integer
   Return CInt(D.AddDays(D.DayOfWeek.Thursday - NormaliserJourSemaine(D.DayOfWeek)).DayOfYear / 7) + 1
 End Function
 Public Function NormaliserJourSemaine(ByVal J As Integer) As Integer
   '.NET ne respecte pas la norme ISO : il retourne 0 pour dimanche
   If J = 0 Then Return 7 Else Return J
 End Function

Voici une proposition pour Visual C++ en utilisant la classe COleDateTime.

#include <afxdisp.h>
int ReturnNumOfWeek(int Year, int Month, int Day)
{
   COleDateTime  Curtime,Le4janv ;
   int JeudiDay,lelundidelapremsem,NumWeek;
   
   if(Curtime.SetDate(Year, Month, Day)) // Si fonction retourne 1 alors erreur et retour -1
     return -1;
   
   //Calcul du jeudi associé au jour de la semaine courante
   JeudiDay = Curtime.GetDayOfYear() + 4 - (int)fmod(Curtime.GetDayOfWeek()-2+7,7);
   //Création de l'objet COleDateTime correpondant au 04/01 de l'année en cours
   Le4janv  = COleDateTime(Curtime.GetYear(),01,04,0,0,0);
   //Calcul du lundi associé
   lelundidelapremsem = 8 - (int)fmod(Le4janv.GetDayOfWeek()-2+7,7);
   
   //Calcul du numéro de la semaine en cours
   NumWeek = int(((double)JeudiDay-(double)lelundidelapremsem)/7.0+0.5)+1;
   
   return NumWeek;	
 }

Il manque des choses

Il serait utile d'avoir la date de création de la norme, et des exemples de commandes permettant d'obtenir la date à ce format.--195.83.89.138 (d) 11 février 2008 à 16:36 (CET)

fraction de seconde

"Si on doit ajouter des décimales... Exemple: T15:23:56,9854" : quel est le séparateur entre partie entière et partie fractionnaire dans la norme ? la virgule ? le point ? les deux ? l'exemple donné semble indiquer que l'usage de la virgule est valide : est-ce bien le cas ? Baldodo (d) 3 septembre 2010 à 14:32 (CEST)

Av. J.C. : contradiction avec l'article anglais

"Il n'y [a] pas de représentation standard des années avant Jésus-Christ, mais certains le permettent avec un accord mutuel en utilisant le préfixe littéral B suivi de 4 chiffres à partir de 0001 pour la désignation classique des années sans 0000, ou le préfixe U suivi d'un signe et de 4 chiffres à partir de 0000 pour l’extension grégorienne proleptique du calendrier UTC".

Ceci est totalement contradictoire avec l'article en langue anglaise : "An expanded year representation [±YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it must be prefixed with a + or − sign[12] instead of the more common AD/BC (or BCE/CE) notation; by convention 1 BC is labelled +0000, 2 BC is labeled -0001, and so on."

Personnellmeent, je n'ai pas accès à la norme. Qui a raison ?

--Dgreusard (discuter) 22 avril 2016 à 11:19 (CEST)

Je dispose du texte de la norme ISO 8601:2004, et il est conforme à ce qu'on peut lire sur en:. Je ne sais pas d'où viennent les préfixes "B" et "U" décrits ici, et il n'y a pas de source (« certains permettent » ?). Cdt. — mro ^[d] 22 avril 2016 à 11:45 (CEST)

 Verdy_p : pourrait nous en dire plus sur ce diff de décembre 2006. — mro ^[d] 22 avril 2016 à 12:22 (CEST)

Vous oubliez de lire un terme important même dans l'article anglais "agreed-upon". Autrement dit ce n'est pas fixé par la norme, et il s'agit d'une convention comme une autre.

La notation avec signe fonctionne à condition d'utiliser un calendrier grégorien proleptique avec l'extension astronomique (où +0000 = -0000 = 0001 BC = 1 av. J.-C.)

Cette notation signée pose probème dès qu'on veut former un intervalle de date (étant donné que le signe "-" est également interprété comme séparateur de dates).

La notation signée vient également en confli avec la notation abrégée ("-1202" en ISO 8601 standard signifie le 2 décembre d'une année non indiquée, et non une année "-1202").

De même "-1964" est souvent interprété comme "jusqu'en 1964" et non pas "1965 av. J.C." dans nombre d'applications. Bref les années signées ne dont PAS partie de la norme ISO 8601!

Pour ces raisons, des applications lèvent l'ambiguité en utilisant le préfixe "U" pour les dates UTC avec extension astronomique et dans ce cas on obtient "U0000" pour 1 av. J.-C., ou avec "B" pour les dates notées de façon plus usuelle sans aucun signe (où "B0001" = "1 av. J.-C.). et il n'y a plsu d'ambiguité alors pour les intervalles de date non plus ("U1964" = 1964 ap. J.-C.; "U-1964" = 1965 av. J.-C.; "-U1964" = jusqu'en 1964 ap. J.-C.)

La norme ISO 8601 en fait ne normalise pas l'ère pré-chrétienne.

Noter aussi que j'ai écrit ça en 2006, il y a 10 ans !!! (il y a peut-être eu des mises à jour depuis dans la norme). A l'époque c'était un sujet discuté aussi dans diverses listes de diccussion pour la normalisation. On en retrouve la trace dans les discussions pour CLDR (bien qu'alors c'était encore un projet collaboratif d'IBM et pas encore géré par le Consortium Unicode). Ces notations viennent d'IBM (ou de plusieurs autres implémentations sous Unix) et elles perdurent encore.

A mon avis il n'y a encore rien dans ISO 8601 qui indique comment noter les années préchrétiennes! Il n'y a que la norme astronomique (qui se fout totalement du calendrier grégorien avec ses jours de durée variables et des "secondes intercalaires" ajoutées aléatoirement de temps en temps uniquement pour réaligner de temps en temps le calendrier civil avec les observations astronomiques, et encore plus des années bissextiles). Ce calendrier se fout également des divisions en mois, semaines et jours mais s'appuie sur la définition normalisée de la seconde du système SI ; dans ce cas les unités "seconde", "minute", "heure", jour", "semaine" dérivées du SI sont de durée fixe, et n'ont jamais à s'aligner avec le calendrier ISO 8601. Ce calendrier astronomique s'exprime avec une seul nombre dans une seule unité, et ce nombre est naturellement signé (et n'a pas besoin non plus de zéros pour obtenir un format fixe).

ISO 8601 n'a jamais été fait pour les astronomes, c'est une norme d'usage civil pour des humains d'aujourd'hui qui peuvent dater des événements récents ou à venir (et une norme moderne qui n'a même pas besoin de prendre en compte les années préchrétiennes, alors qu'on n'a même pas assez d'informations pour dater précisément ces événements lointains (il y a une grande incertitude concernant les 12 premières années de l'ère chrétienne, dont le début est fixé de façon complètement arbitraire dans le calendrier grégorien proleptique. Pour les applications qui demandent aujourd'hui une grande précision des dates (exemple le GPS), ISO 8601 ne sert à rien, le calendrier de référence est basé sur une horloge atomique à pas constant, et le BIPM publient des mesures de correction de l'écart entre cette horloge atomique et notre calendrier civil international, uniquement pour corriger ce dernier calendrier ; il n'y a jamais eu de telles corrections avant les années 1960, à compter des premiers lancements d'engins spatiaux !

Même encore aujourd'hui de nombreux logiciels ne savent pas calculer (ni même stocker correctement) des dates avant 1970 de notre ère. Verdy p (discuter) 23 avril 2016 à 01:12 (CEST)

Je cite la norme ici

2.2.13 calendar year
cyclic time interval in a calendar which is required for one revolution of the Earth around the Sun and approximated to an integral number of calendar days
Note 1 to entry: A calendar year is often also referred to as year.
Note 2 to entry: Unless otherwise specified the term designates in this International Standard a calendar year in the Gregorian calendar.

La note 2 dit bien qu'une année au sens de la norme concerne une année calendaire dans le calendrier grégorien, dont ne font partie aucune des années préchrétiennes. Elle n'est même pas applicable aux calendrier grégorien proleptique (défini à postériori mais où on doit séparer les deux ères).

2.2.15 Gregorian calendar
calendar in general use, introduced in 1582 to define a calendar year that more closely approximated the tropical year than the Julian calendar
Note 1 to entry: In this International Standard the term Gregorian calendar is used to refer to the time scale described in 3.2.1.

La définition donne une limite: rien n'est normalisé avant 1582 de notre ère !

ISO 8601 indique aussi dans la section "2.3.8 expanded representation" l'existence d'expansion de representation "to allow identification of dates in calendar years outside the range [0000] till [9999]" mais elle ne précise aucun format en particulier et impose l'accord préalable mutuel.

ISO 8101 pour cela définit ce qu'on appelle un "profil" d'utilisation (par exemple le W3C définit un profil simplifié mais suffisant pour l'usage des dates dans des données formattées en XML, et l'IETF a un profil étendu utilisant aussi d'autres formats, dont les formats mentionnant explicitement l'ère, mais jamais un profil utilisant des "années négatives ou nulles"). Aucun de ces profils n'a défini une quelconque extension "proleptique" du calendrien grégorien. Même la norme "UTC" (temps universel) ne définit pas de telle extension. La seule norme que je connaisse et qui l'a fait c'est le calendrier astronomique, qui ne s'appuie PAS du tout sur le calendrier UTC mais ne saccorde avec lui qu'avec les ajustements intercalaires publiés par le BIPM (qui n'a publié justement aucun ajustement avant la fin du XXe siècle puisque les mesures précises n'ont jamais existé avant).

Verdy p (discuter) 23 avril 2016 à 01:30 (CEST)

Dernière note: la norme ISO 8601: a été initialement publiée en 1988, avec quelques modifications et corrigenda jusqu'en 2004, mais elle est obsolète et remplacée par ISO/CD 8601-1.qui vient d'être publiée en 2016 (je n'ai pas le détail des modifications) Verdy p (discuter) 23 avril 2016 à 01:52 (CEST)

Tout cela est fort intéressant, mais cela nous éloigne du sujet de l'article qui est la norme ISO 8601, et où sont les sources ? Je propose de nous en tenir à ce qui est sourcé et directement lié à la norme, autrement dit de ne pas faire mention des préfixes "U" et "B" qui sont étrangers à celle-ci. Je fais aussi observer que dans le texte de la norme on trouve cet exemple (p. 27) :

−00020412 −0002-04-12 Expanded; four digits to represent the year. The twelfth of April in the second year before the year [0000]

Ce qui est naturellement un format étendu, mais montre que le format avec un - n'est pas si étrange. — mro ^[d] 24 avril 2016 à 22:05 (CEST)

Y'a-t-il réellement une ambiguïté ?

Dans la section « Durée », il est précisé qu'il y a « il y a ambiguïté durée exacte de l'année dans le contexte de durée ». Cette ambiguïté n'a lieu qui on tente de convertir cette durée en jours. Mais tout l'intérêt de ce formalise est justement de pouvoir exprimer des durée qu'on ne peut pas traduire en nombre de jour !

Il est absolument normal de ne pas spécifier la durée exacte en jour d'un mois : il n'en existe pas, étant donné que tous les mois n'ont pas la même durée ! Spécifier que P1M équivaut à P30D ferait que P1M ne représenterait plus un mois mais 30 jours, et rendrait son utilisation redondante en plus de rendre l'expression d'un mois impossible.

Entre le 01 janvier 2015 à 10 heures et le 30 décembre 2015 à 10 heures (j'ai mis la même heure pour simplifier la discussion), il ne s'est pas écoulé 12 mois et 3 jours (durée de l'exemple de l'article), il s'est écoulé 11 mois et 29 jours. Il est donc naturel d'écrire P11M29D.

L'ambiguïté pourrait exister pour la Seconde intercalaire, car une heure comme équivalent à 3600 secondes. La durée entre le 30 juin 1985 à 23h et le 1er juillet 1985 à 01h est de 7201 secondes (une seconde intercalaire a été introduite), la durée est-elle de 2h (P2H) ou de 2 heures et 1 seconde (P2H1S) ?