Byta datumstandard från ISO 8601 till RFC 3339

[karatekaneen]

Alla datum och tider i specifikationen är definierade som att de ska följa ISO 8601. Detta är lite problematiskt eftersom ISO 8601 är otroligt bred och för oss kräver den extra dependencies enbart för att parsa datum för att försäkra oss om att vi uppfyller specen.

Exempel på hur dagens datum, 2023-12-09 skulle vara okej att formateras idag:

• 2023-W49-5
• +002023-W49-5
• +0020231208T095152Z
• 2023-342
• P1Y2.5MT4H

Därför föreslår jag att vi byter allt till RFC 3339 vilket dessutom är idiomatiskt för JSON och stöds av alla språk. Bör inte påverka något praktiskt mer än att vi kan använda standardfunktioner i respektive språk istället för att ha stöd för att parsa alla olika format.

Jag tror dessutom att RFC 3339 var vad som egentligen avseddes med specifikationen.

Vidare läsning

1. https://ijmacd.github.io/rfc3339-iso8601/
2. https://en.wikipedia.org/wiki/ISO_8601

[stefanostman]

Inte så jag läser ISO8601. Vad jag läser så ser det väl ut som båda standarderna överlappar avseende att hantera både "2023-12-08" och "2022-10-01T22:18:17+02:00" som är de format som används om vi tar bort tiden på emaSubmisssionDate

Men har det betydelse för kodningen så kan jag inte se att det på något vis påverkar. Är det mer enligt JSON-standard så ska vi väl absolut använda det istället

[karatekaneen]

@stefanostman RFC 3339 är ett subset av ISO 8601. Vilket innebär att alla datumen jag skrev där uppe hade varit okej att skicka till er som timestamps idag. Jag misstänker dock att ni parsar det som YYYY-MM-DD. Så genom att begränsa oss till RFC 3339 så kommer vi inte behöva parsa något i stil med "P1Y2.5MT4H", någonsin.

[stefanostman]

Är väl mer av att vara tydlig i specifikationen än något som påkallar någon åtgärd. Vi på LV skulle åtminstone inte få för oss att publicera något annat format än vad som kan anses vara standard. Och Ja vi förutsätter att datum kommer till oss som "YYYY-MM-DD" eller "YYYY-MM-DD HH:MM:SS" Jag kan absolut ändra till "Datum enligt RFC 3339" i Definitionen i samband med att vi gör justeringarna av booleaner och nullvärden som väl kommer att behöva hanteras som en Major-uppdatering.

[tomassna]

Det förefaller som att vi är överens om att vi redan använder det striktare formatet i RFC 3339. Jag ska erkänna att jag inte var införstådd med att man kunde blanda vecko formaten i tidsangivelserna enligt exemplet men det är inte något som vi fått för oss att göra. Då antar jag att det bara är att uppdatera dokumentationen vilket jag skulle säga inte ens kräver en tagg i versionsnummret. Med tanke på att det beskriver vad som redan är implemetnerat kan man snarast se det som en rättning av dokumentationen.

Nu gissar jag att ingen av oss faktiskt använder schemat automatiserat vid skickande/mottagande av meddelanden än men @stefanostman har en poäng i att vi behöver en ny major för ett par saker kring hur null-värden representeras samt boolska variabler som råkat bli strängar.

[karatekaneen]

Jo, att vi följer RFC 3339 redan idag gör ju det här till ett dokumentationsproblem snarare än något annat. Anledningen till att jag tar upp det är för att vi ska vara säkra på att det inte kommer något knasigt formaterat datum från en tredjepartstjänst (typ CTIS) som efterlever ISO8601 men som man helst inte vill hantera.

På så sätt så slipper vi bygga in garderingar för det för att kunna efterleva specifikationen.

[stefanostman]

Jag uppdaterar dokumentet och lägger upp det i GIT. Bra om vi kan tömma Teamsytan. Även om de sannolikt ligger mer oåtkomliga på teams än de gör i GIT. En fråga vi nog bör prata om är hur tillgängligt GIT-repot ska vara. Det får ju inte bli så att vi exponerar info som gör oss mer sårbara.

[tomassna]

Vi har börjat testa att validera gamla meddelanden mot schema och inser att vi behöver ta upp en sak här. Jag inser från kommentarerna tidigare att jag kan ha missat någon fråga kring emaSubmissionDate men den har vi ett problem med i samtliga meddelanden som vi fått hittills. Oaktat frågan om ISO 8601 eller subsetet RFC3339 så har vi ett issue med att det kommer utan info om local offset, vilket är obligatoriskt i den validerare vi har testat att använda. Jag antar att förelaget att begränsa det till att vara bara ett datum är en enkel lösning på problemet.