Jesper Lund Stocholm bloghoved

ISO-8601 datoer - den sidste knast

Er der nogen af jer, der kan huske, hvad der skete i slutningen af februar i 2008?

Jo - for de af jer, der ikke er helt med, så mødtes en masse mennesker i et konferencelokale i Geneve for at rede trådene ud efter den indledende afstemning om det, er endte med at blive ISO/IEC 29500:2008 - af venner og fjender også kendt som "OOXML".

Vi havde en del på tapetet i den uge - herunder at ændre datoformatet i regneark. I det oprindeligt indsendte forslag blev datoer gemt som numeriske værdier - men dette blev hurtigt en politisk varm kartoffel - og derfor højt på vores agenda i Geneve.

Det var den tyske delegation, der ledte det tekniske arbejde med at få detaljerne på plads - i samarbejde med en to-tre håndfulde delegerede fra andre lande. Jeg husker stadig hvordan de stod nærmest ovenpå hinanden for at være med under snakkene i korridorene udenfor mødelokalet. At der var mange kokke - og at emnet var både politisk og komplekst understregedes af, at dokumentet vi vedtog dernede var i "version 9" inden de blev færdige.

Nå - men fokus af deres arbejde afsløres i de indledende sætninger i dokumentet:

We agree that it is important for SpreadsheetML to support ISO 8601 dates, and that the current specification could be improved in several ways:

  • The ability to store values as dates, rather than as numeric serial values formatted as dates
  • Support for dates before 1900
  • Proper treatment of 1900 as not being a leap year

No offense - men de ting man gjorde var ikke helt gennemtænkte.

Korrektionerne var i store træk:

  1. Indførsel af en attribut i regneark, der angav om 1900 skulle anses som et skudår (den legendariske Lotus 1-2-3 bug)
  2. Specifikation af, at datoer i regneark skulle gemmes i ISO-8601 format
  3. Datoer blev tilladt i intervallet -9999 til 9999

Men dette gav alle mulige problemer. ISO-8601 formatet smadrede eksempelvis alle eksisterende applikationer, der alle nu begyndte at regne forkert, dato-intervallet gav problemer med årstal før år 0 (pga
manglende specifikation af år 0) og selvom mange regnede med, at "når vi bruger ISO-8601, så forsvinder skudårsbug).

Vi var derfor nødt til at gøre noget - og reelt startede dette arbejde på det første møde vi havde i Okinawa i januar 2009. Der blev nedsat en decideret arbejdegruppe med nogle SME'er for regneark og andre
eksperter (herunder CIBERs repræsentant, dvs jeg), der havde en generel interesse i problemstillingen bidrog også med input.

Den første erkendelse vi nåede var, at vi havde behov for at definere en profil for ISO-8601, der var rettet imod anvendelse i regneark. ISO-8601 er en uhyre omfattende standard, der reelt favner stort set
alt, hvad vi kan anse som "en dato". Men anvendelsen af datoer i regneark udfylder ikke hele dette udfaldsrum, så en profil af ISO-8601 virkede som en god idé.

Profilering af ISO-8601 er bestemt ikke unormalt - ja, men kan næsten sige, at det er en forudsætning for anvendelsen af den på ne interoperabel måde, da den er så omfattende.

Følgende er nogle af de profiler, som i dag eksisterer:

![Eksternt billede](http://www.version2.dk/modules/xphoto/cache/29/7229.png" alt=")

Vi gik i gang med at afdække brugsmønstrene for anvendelse af datoer i regneark, og vi kiggede bla på ting som

  • Anvendes tids-zoner'
  • Hvilket interval ligger datoer i'
  • Hvilket økosystem lever regneark i? (ifht automatiserede processer)

Og endelig: hvad gør andre? (primært ODF)

For idéen med at lave en(dnu) profil af ISO-8601 er jo ikke blot at få noget at lave. Idéen er at maksimere interoperabilitet. Hvis noget i en givet specifikation er løst beskrevet - så er det så sikkert som
amen i kirken, at det vil bevirke nedgang i interoperabilitet imellem applikationer, der har fortolket de løse beskrivelser forskelligt. Da datoer er super vigtige i regneark, er det super vigtigt, at vi får
tunet beskrivelserne omkring datoer.

Først kiggede vi på, hvad man gør i ODF. I ODF (ODF 1.2 draft CD04) specificeres dato-anvendelse i regneark som "either an [xmlschema-2] date value or an [xmlschema-2] dateTime value." Der tales om W3C
Schema
specifikationen, og her står der bla. om datoer:

"The ·value space· of dateTime is closely related to the dates and times described in ISO 8601."

Der er nogle forskelle på W3C Schemas datetime og ISO-8601, hvor bla. ugeangivelse er tilladt og det leksikalske (hedder det der?) udfaldsrum er indsnævret en del, men i de fleste praktiske tilfælde er der ikke den store forskel.

Og det er et problem.

For med en standard som ISO-8601, der er voldsomt stor og kompleks, så giver sætningen "datoer gemmes som ISO-8601" ikke megen mening. Problemet er nemlig, at der ikke er nogen regneark, der understøtter "det hele". For udviklere er dette uheldigt, for det efterlader os på herrens mark, når vi skal arbejde med data i - i dette tilfælde - regneark. Vi kan nemlig ikke nøjes med at kigge i specifikationen - vi er nødt til at teste imod alle de (større) implementeringer af standarden for at få svar på de usikkerheder de løse formuleringer giver os.

Endelig kiggede vi på det økosystem som regneark lever i. Regneark bruges i stor grad som input-container for automatiserede processer og data fra dem stammer ofte fra databaser eller data ender deres liv i databaser efter de er dannet i et regneark. Derfor er en eller anden form for kompatibilitet med databaser ønskelig.

Det syntaktiske lag ovenpå de rå data er SQL-standarden - også kendt som ISO/IEC 9075-1:2008. Den er også en profil af ISO-8601, og indsvævres bla. til:

  • Den implementerer den gregorianske kalender i henhold til ISO-8601
  • Den har et max-år på 9999
  • Den har en min-dato på 0001-01-01

Dette er i høj grad en kandidat til efterfølgelse i vores OOXML-profil - ikke mindst pga dens markedsrelevans og udbredelse.

Men desværre implementerer alle databaser ikke SQL-profilen af ISO-8601 på samme måde. Et par eksempler på dette er:

ORACLE

  • Min-dato på -4712-01-01
  • Bruger ikke den gregorianske kalender

SQL Server 6.5-2000

  • Min-dato på 1753-01-01

MySQL

  • Min-dato på 1000-01-01

SQL-server 2008

  • Anvender gregorianske kalender korrekt
  • Min-dato på 0001-01-01

IBM DB2

  • Anvender gregorianske kalender korrekt
  • Min-dato på 0001-01-01

Når man tager alle ovenstående hensyn i betragtning (+ nogle jeg ikke har kunnet komme ind på her), så er vi kommet med følgende anbefaling til en OOXML-profil af ISO-8601:

Min-dato på 0001-01-01

Max-dato på 9999-12-31

Datoer angives med følgende format (specificeret i ISO 8601 B.1.1, B2.1)

  • YYYY-MM-DD - Eksempel:'1985-04-12'

Tid angives med følgende format: (specificeret i ISO 8601 B.1.2, B2.2)

  • hhmmss - Eksempel: '15:27:46.000'

Dato og tid angives med følgende format

  • YYYY-MM-DDThhmmss - Eksempel:'1985-04-12T15:27:46.000'

Og for formler:

  • Formler, der arbejder med tid og datoer modtager numeriske værdier i runtime
  • Formler, der arbejder med tid og datoer returnerer numeriske værdier i runtime
  • Datoer gemmes som ISO-8601 i Strict (med begrænsningerne ovenfor)
  • Datoer gemmes som numeriske værdier i Transitional

Afvigelserne fra ISO-8601 bliver dermed bla.:

  • Antallet af decimaler indsnævres til 3
  • Komprimerede formater som 19850412 tillades ikke
  • Dagstal-angivelse som 1985-102 tillades ikke
  • Ugedage som 1985-W15-5 tillades ikke
  • Ugenummerangivelse som 1985-W15 tillades ikke
  • Månedsnummerangivelse som 1985-04 tillades ikke
  • Seperat årsangivelse som 1985 tillades ikke
  • Decimaladskiller angives som punktum
  • Tidsintervaller tillades ikke
  • Tilbagevendende tidsintervaller tillades ikke
  • Midnat defineres som 00:00 og 24:00 tillades ikke
  • Alle tidsangivelser er lokale, dvs uden tidszoneangivelse

Og endelig (men det har principielt ikke noget med ISO-8601 profiling at gøre), så fjernes muligheden for at angive 1900 som værende et skudår fra . Det har været en høj prioritet for mig og også det danske udvalg i dokumentformatstandardisering, så vi er glade for, at denne mulighed nu ikke længere findes i .

Kommentarer (70)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Poul-Henning Kamp Blogger

Jeg synes I skulle konsultere forfatterne til bogen "Calendrical Calculations" for der er nogle semantiske forhold omkring specielt datoer i fortiden der kan blive utroligt komplekse.

Enhver der arbejder med datoer og tider før Longitude Konference i 1884 (?) bliver nødt til at gøre sig klart hvad og hvor dato og tid kommer fra og hvorledes det skal behandles.

Derfor vil det sandsynligvis være klogt at forbyde anvendelse af UTC/GMT baserede tidsangivelser før dette punkt, check med forfatterne ovenfor om der evt er en tidligere "sikker" dato end konferencens ratifikation.

For ting der ligger tidligere er den eneste universelt sikre tidskala sÅ vidt jeg ved MJD, men igen, check med forfatterne.

For alt hvad der ligger efter konferencen, kan UTC+offset bruges og der bør gøres explicit for regnearket hvilket offset/tidszone der skal anvendes.

Det vil tillade forskere at lave "UTC" regneark hvor tidsangivelser ikke forvanskes af at modtageren lever i en anden tidszone.

Samtidig vil forretningsfolk bekvemt kunne aftale telefonmøder ved at sætte tidszonen til "local", således at alle der modtager dokumentet ser tiden angivet i lokal tid.

Og endelig kan man naturligvis angive en specifik tidszone, således at alle der åbner dokumentet ser hvad tid der var tale om i PDT, CET eller hvor ting nu skete.

(Se: "cal 1752" for hvorfor det er vigtigt)

Poul-Henning

  • 0
  • 0
#3 Jesper Lund Stocholm Blogger

Hej Poul-Henning,

Tak for dit indspark. Helt generelt er beregninger på datoer out-of-scope - det applikationsspecifik opførsel. Det "eneste" vi bekymrer os om er, hvordan datoer og tidsangivelser persisteres i dokumentformatet.

Vi har diskuteret anvendelsen af tidszoner flere gange - og også i udvalget i Danmark. Vores konklusion er, at der ikke er én eneste regnearksimplementering, der understøtter angivelse af tidszoner, så derfor er de ikke tilladt. Hvis en leverandør kommer med en implementering af det til os i et produkt, så vil vi kigge på det igen, men vi har vurderet, at tilladelse af tidszoner ville blive en kompleks opgave at implementere i dokumentformatet, og da ingen pt. ønsker/anvender det, så ønsker vi ikke at begive os i kast med denne "standardisation-by-committee"-opgave nu

  • 0
  • 0
#4 Poul-Henning Kamp Blogger

Vi har diskuteret anvendelsen af tidszoner flere gange - og også i udvalget i Danmark. Vores konklusion er, at der ikke er én eneste regnearksimplementering, der understøtter angivelse af tidszoner, så derfor er de ikke tilladt.

Hallo!

Hvad er det I har gang i ?

Prøver I på at lave et flot gummistempel til existerende produkter, eller prøver I på at lave et standardiseret filformat vi kan bruge i fremtiden ?

Gør det dog rigtigt for en gangs skyld, istedet for at lave endnu en bekvem klamphuggerløsning der bare giver flere problemer end den løser.

Poul-Henning

  • 0
  • 0
#5 Jesper Lund Stocholm Blogger

Hej Poul-Henning,

Prøver I på at lave et flot gummistempel til existerende produkter, eller prøver I på at lave et standardiseret filformat vi kan bruge i fremtiden ?

Vi har på ingen måde afskrevet os muligheden for at tillade tidszoneangivelse engang i fremtiden - skulle behovet opstå for det.

Men der er ikke et behov [0] for det i øjeblikket, så derfor tillades det ikke.

Skulle du ikke have fanget det ovenfor, så er målet at maksimere interoperabilitet og ikke at agere gummistempel. Tror du i øvrigt selv, at det på nogen måde er et selling-point ifht "produkt x vs. produkt y", om den ene anvender "ISO/IEC 29500 ISO-8601 profil til persistering af dato- og tidsangivelser?

[0] "Behov" defineres som: "Ingen leverandører og ingen andre deltagere i standardiseringsarbejdet har ytret ønske om at tidszoner skulle tillades".

  • 0
  • 0
#6 Erik Cederstrand

Vi har diskuteret anvendelsen af tidszoner flere gange - og også i udvalget i Danmark. Vores konklusion er, at der ikke er én eneste regnearksimplementering, der understøtter angivelse af tidszoner, så derfor er de ikke tilladt.

Så specificér i det mindste, at datoer i dokumentformatet altid er i UTC. Så kan de forskellige implementeringer selv bestemme, om de vil understøtte tidszoner.

En dato uden tidszone er som en tekststreng uden encoding. Eller en højde uden nulpunkt. Eller en pris uden valuta. Eller et dokumentformat uden versionsnummer. Eller...

Og så har jeg slet ikke nævnt skudsekunder.

  • 0
  • 0
#7 Poul-Henning Kamp Blogger

[0] "Behov" defineres som: "Ingen leverandører og ingen andre deltagere i standardiseringsarbejdet har ytret ønske om at tidszoner skulle tillades".

Læs: Vi aner ikke en skid om det, så vi skriver bare hvad der er mest bekvemt for os.

Det var den måde vi endte med "time_t" katastrofen, der er "UTC uden skudsekunder.

Hvad med at henvende jer til verdens ypperste forskere i kalendrer og få dem til at hjælpe med at lave en kompetent standard ?

Kan du forstille dig et udvalg der skal lave standarder for bygningsstabilitet sige "Vi ved ikke noget om noget om aluminium, så vi har bare skrevet at det sikkert er det samme som stål" ?

Nej vel ?

Tag jer nu sammen og vis at det ikke er en ren skue-process!

Standarder skrives for hjælpe fremtiden, ikke for at godkende fortidens fejl.

Poul-Henning

  • 0
  • 0
#8 Michael Mortensen

Som udganspunkt bør ISO8601 ALTID benyttes når der udveksles dato informationer i XML - punktum!

Som en ekstra bonus ville det jo kun være godt, hvis udviklere rent faktisk benyttede UTC frem for de til tider forskellige tidszoneangivelser der findes i div. installationer rundt omkring.

Hvis du udvikler i eks. .NET rammeværket, så gør dig selv og dine kollegaer en tjeneste; opnå indgående kendskab til System.Globalization området - samt naturligvis håndtering af datoer.

"Don't assume a damn thing!"

  • 0
  • 0
#9 Poul-Henning Kamp Blogger

UTC alene løser ikke problemet, du er nødt til at vide "UTC+representations offset"

En slankekur der siger "Mandag 09:00 en fersken" er et lokalrelativt tidspunkt, et regneark der siger "Supernova 7 2011-04-08 01:58:33" er et universelt unikt tidspunkt der aldrig må pilles med. "Jeg ringer klokken 9" skal justeres til lokal tid for modtageren.

Poul-Henning

  • 0
  • 0
#10 Svenne Krap

[0] "Behov" defineres som: "Ingen leverandører og ingen andre deltagere i standardiseringsarbejdet har ytret ønske om at tidszoner skulle tillades".

Det er nu ikke helt korrekt, jeg har ved mindst to møder ytret ønske om tidszoner.

Jeg vedgiver at jeg hver gang er blevet talt fra det - men ønsket har været ytret ... repeatedly ... :)

  • 1
  • 0
#11 Michael Mortensen

UTC alene løser ikke problemet, du er nødt til at vide "UTC+representations offset"

Det er jeg klar over - beklager jeg ikke var mere konkret i mit oplæg, men det ændre dog ikke mit synspunkt - tværtimod forstærker dine supplerende oplysninger det blot.

I øvrigt er jeg meget enig i det du skriver i dette indlæg, omend retoriken er meget .. hmm .. kontant :-)

  • 0
  • 0
#12 Jesper Lund Stocholm Blogger

Hej Erik,

Så specificér i det mindste, at datoer i dokumentformatet altid er i UTC. Så kan de forskellige implementeringer selv bestemme, om de vil understøtte tidszoner.

Vi er ved at planlægge mødet i Beijing i december, og her kunne en oversigt over agendaen for dag 1 se således ud:

Jesper 08:30 - 10:00 Thorsten 10:15 - 11:45 Gareth 13:00 - 14:30

Hvis jeg tamper disse ind i et regneark - hvad forestiller du dig så, at der skal ske?

På indtastningstidspunktet i Danmark? På åbningstidspunktet i Japan, i USA, i England?

  • 0
  • 0
#13 Jesper Lund Stocholm Blogger

Hej Poul-Henning,

Kan du forstille dig et udvalg der skal lave standarder for bygningsstabilitet sige "Vi ved ikke noget om noget om aluminium, så vi har bare skrevet at det sikkert er det samme som stål" ?

Nej - det kunne jeg ikke.

Men jeg kunne godt forestille mig følgende:

Et standardiseringsudvalg for en dansk standard for byggestabilitet bestående at en række SME'er med årelang erfaring i netop dette emne. Med ved bordet sidder også en deltager, der ingen erfaring har med emnet - men som trods dette vedbliver at insistere på, at der i standarden også skal tages hensyn til stabilitetsberegninger, der foregår i tyngdekraft svarende til en sjettedel af Jordens ... "for det kunne jo være super fedt, hvis den danske standard blev brugt, når Månen engang blev beboet".

Det kunne jeg faktisk godt forestille mig.

  • 0
  • 0
#15 Jesper Lund Stocholm Blogger

Hej Svenne,

Det er nu ikke helt korrekt, jeg har ved mindst to møder ytret ønske om tidszoner.

Jeg vedgiver at jeg hver gang er blevet talt fra det - men ønsket har været ytret ... repeatedly ... :)

Det er helt korrekt - DKUUG har flere gange talt for at inkludere tidszoner i udfaldsrummet, men vi er i udvalget hver gang blevet enige om, at det eksisterende forslag var godt for nu.

Referatet fra sidste møde, hvor vi diskuterede dette i langt flere detaljer end dette blogindlæg tillader og hvor vi havde én af WG4s SME'er stående standby i telefonen fra USA hvis vi skulle bruge ham (ok, han sov, men vi kunne vække ham), kan i øvrigt ses på http://www.ds.dk/da-DK/ydelser/Standardisering/S-udvalg/S-445/Documents/... .

:o)

  • 0
  • 0
#16 Poul-Henning Kamp Blogger

Vi er ved at planlægge mødet i Beijing i december, og her kunne en oversigt over agendaen for dag 1 se således ud:

Jesper 08:30 - 10:00 Thorsten 10:15 - 11:45 Gareth 13:00 - 14:30

Hvis jeg tamper disse ind i et regneark - hvad forestiller du dig så, at der skal ske?

At regnearket tvinger dig til at forholde dig til hvilken slags tidspunkter du har indtastet ved at forlange at du enten vælger "lokal" eller en specifik tidszone.

Hvis du vælger "lokal" er det modtagerens problem at oversætte det til hvad tid han skal se web-cast'en i Peru, så vil der altid stå "09:00" for alle brugere over hele universet.

Hvis du derimod specificerer at det er kinesisk tid (de har kun en tidszone så vidt jeg husker) vil fyren i Peru se feltet formateret som "09:00 (CST)".

Hvis han derefter vælger "show local times" skifter feltet til at vise hans lokale tidszone og han slipper for at tænke på hvad tidsforskellen til Kina mon er og om der er sommer/vintertid for tiden.

Er det ikke netop den slags ting computere skulle gøre nemmere for mennesker ?

Do the right thing, Luke

Poul-Henning

  • 0
  • 0
#19 Jesper Lund Stocholm Blogger

Hej Poul-Henning,

Er det ikke netop den slags ting computere skulle gøre nemmere for mennesker ?

Jo - men der er ingen, der har fundet det betimeligt at implementere i de applikationer, der arbejder med regneark.

Do the right thing, Luke

Jeps - og det rigtige er her at maksimere interoperabiliteten via OOXML og den profil vi har lavet. Hvis du i dine OOXML-filer ønsker at anvende tidszoner eller implementere det du beskriver herover, så står det dig frit for - dine dokumenter bliver ikke invalide af den grund. Når der på et tidspunkt kommer nogen til os og siger, at nu har de i deres implementering vist, hvordan det gøres og de har brugere, der anvender det, så kigger vi på det igen.

"Det rigtige" (tm) er [b]ikke[/b] at indføje funktionalitet, som måske nok er korrekt i teorien, men som ingen har implementeret og ingen har efterspurgt konkret via use-cases fra den virkelige verden.

  • 0
  • 0
#21 Poul-Henning Kamp Blogger

Jo - men der er ingen, der har fundet det betimeligt at implementere i de applikationer, der arbejder med regneark.

Du tror åbenbart stadig i er ved at skrive en brugermanual ?

Det er i ikke, I er ved at skrive en dokumentstandard!

Hvis ikke I tænker på hvorledes dette problem skal løses og laver plads i formatet til at gemme kvalificeringen af tidsfeltet, bliver det ikke muligt efterfølgende at tilføje denne funktionalitet.

Det understreger for mig blot at OOXML er en skueprocess der handler om at få et ISO-GODKENDT stempel på Microsofts makværk.

Poul-Henning

  • 0
  • 0
#23 Jesper Lund Stocholm Blogger

Hej Poul-Henning,

Det er i ikke, I er ved at skrive en dokumentstandard!

Det er vi ganske klar over - og den har som mål at medvirke til, at applikationer, der er skrevet efter den, arbejder sammen på så gnidningsfri en måde som overhovedet muligt.

At tillade tidszoner i ISO-datoerne er et skridt i den stik modsatte retning.

Det understreger for mig blot at OOXML er en skueprocess der handler om at få et ISO-GODKENDT stempel på Microsofts makværk.

Tja - din kommentar her understreger for mig blot, at du stadig absolut ingen viden har om området endsige økosystemet omkring dokumentstandarder som ODF og OOXML.

At tro at Microsoft skulle synes, at anvendelse af ISO-datoer i OOXML er en super god idé viser desværre, hvor frugtesløst det mange gange er at diskutere noget som helst med dig, der er relateret til Microsoft på en eller anden vis. Det er IKKE en Microsoft ting.

Lidt historie: ISO-8601 anvendelse i OOXML var bestemt ikke Microsofts idé - det var end ikke med i den oprindelige version af OOXML. Det kom derimod med på foranledning af Microsofts konkurrenter som IBM, Novell, Redhat, Google, ORACLE, OSL, DKUUG m.fl. Profileringen af ISO-8601 er sket med input fra bla. Novell og DataWatch - hvor sidstnævnte lever og ånder for regneark ... reelt i langt højere grad end Microsoft gør.

At du kalder det "ISO-stempel på Microsofts makværk" viser desværre, hvor lidt du er interesseret i at høre på andre, hvor lidt du er interesseret i fakta - men derimod hvor meget du er interesseret i at høre din egen stemme. Du har det tilsyneladende varmt og godt nede i din skyttegrav, men helt ærligt, Poul-Henning ... det er tudeåndssvagt.

Og slutteligt: i din iver efter at høre din egen stemme igen, overså du åbenbart at jeg skrev, at profileringen blot er vores råd og vejledning til udviklere, der skal implementere OOXML. Det er vores måde at sige til dem, at ønsker I at maksimere jeres interoperabilitet med andre kontorpakker, så følg disse råd. Hvis du ønsker at ignorere denne vejledning, så står det dig frit for. Du skal være velkommen til at anvende lige præcist den nuance af ISO-8601 du ønsker.

  • 0
  • 0
#25 Eskild Nielsen

Gid det var så vel at en standardiseringsgruppe kunne sige:

'Alle de input dokumenter vi har fået er usammenhængende vrøvl, og løser ikke problemet på en fremtidssikker måde'

I det generelle tilfælde skal der være begrundede, skriftlige forslag til tekst som skal indgå i slutresultatet - som regel rundsendt i gruppen i temmelig god tid, så argumenter og modargumenter kan være klar til Diskussionen i Gruppen.

Så indtil 'nogen' skriver et argumenteret forslag til hvordan ISO8601 datoer i de 2 dokumentformater kan udvides med tidszone til senere brug, så sker der med sikkerhed ikke noget.

  • 0
  • 0
#27 Michael Rasmussen

Opfandt i noget nyt eller genbrugte i ODF løsningen?

De opfandt noget nyt, nemlig at udelade tidszonen. For xmlschema-2 dateTime[0] er timezone obligatorisk, mens det gælder for xmlschema-2 date[1], at timzone er valgfrit.

Så at tale om interoperabilitet mellem regnearksformater er vist tilsnigelse. Der kan måske tales om interoperabilitet mellem forskellige versioner af XLS og XLSX.

[0]http://www.w3.org/TR/xmlschema-2/#dateTime pkt. 3.2.7.3 [1]http://www.w3.org/TR/xmlschema-2/#date pkt. 3.2.9

  • 0
  • 0
#30 Jesper Lund Stocholm Blogger

Hek Eskild,

Opfandt i noget nyt eller genbrugte i ODF løsningen?

I vore øjne gør ODF ikke nok for at sikre større interoperabilitet. Man genbruger xsd:date og xsd:datetime, men uden at tage hensyn til brugsmønstrene i regneark.

Problemet er jo, at hvis jeg i ODF læser specifikationen af anvendelse af datoer, så er bla. tidszoner tilladte - og det kunne jeg som implementør så finde på at putte i mine ODF-filer.

... men der er ikke en eneste ODF-applikation, der understøtter dette - de ignorerer alle tidszonen, når de loades. Derfor hæmmes interop i ODF-verdenen (på dette område), hvis jeg følger spec - for den følger ikke den verden specifikationen anvendes i.

Derfor har vi i OOXML valgt at anbefale (ikke kræve) en bestemt begrænsning/profilering af ISO-8601. Hvis du ikke ønsker at anvende den, så er det dit valg, men det er standardiseringsgruppens råd til dig, hvis du er interesseret i, at dine regneark skal kunne anvendes af så mange applikationer som muligt.

  • 0
  • 0
#34 Jesper Lund Stocholm Blogger

Hej Poul-Henning,

Standardisering af et dokumentformat bør ikke handle om hvilken software forskellige klamphuggere har skrevet i fortiden, men om hvorledes vi kommunikerer i fremtiden.

Wov ... så nu skal vi til at spå om, hvad fremtiden måtte bringe?

Det afgørende er, at vi fastlægger, hvordan vi kommunikerer [b]i dag[/b] - samtidig med, at vi ikke skaber forhindringer for nyudvikling i fremtiden. Og det er [b]præcist[/b] det vi gør nu med OOXML og vores vejledning til anvendelse af datoer. Der er INTET, der forhindrer os i at tillade tidszone-angivelse engang i fremtiden.

... det skulle da lige være tidsbekneb efter at have brugt alt for lang tid på at diskutere ligegyldige ting med dig.

Tilbage til skyttegraven, Pølle.

  • 0
  • 0
#36 Lars Lundin

Jeg synes I skulle konsultere forfatterne til bogen "Calendrical Calculations" for der er nogle semantiske forhold omkring specielt datoer i fortiden der kan blive utroligt komplekse.

Enig. Eskild Nielsen er inde på det samme.

Min egen "syretest" er håndteringen af datoen 1712-02-30 (!), som med svensk (og kun svensk) locale er en lovlig dato.

  • 0
  • 0
#37 Lars Lundin

Lad mig gætte - Sverige fik den ny kalender det år?

Det er rigtigt gættet at det har med Sveriges overgang til den Gregorianske kalender at gøre. Det er en lang historie, som f.eks. kan læses her:

http://en.wikipedia.org/wiki/Swedish_calendar

Omvendt fik Danmark - efter min mening - den mindst forvirrende overgang til den Gregorianske kalender, takket være Ole Rømer.

Iøvrigt har ovenstående debat bestyrket min overbevisning om at OOXML er noget der skal undgås.

PS. Jeg fik skrevet 1812-02-30, det skal være 1712-02-30.

  • 0
  • 0
#39 Claus Bruun

@Jesper

"Så skal du nok ikke bruge et regneark til at håndtere dine logfiler?"

Meget morsomt - det gør jeg nok heller ikke, men meget ofte bruger man regneark til at kommunikere diverse uddrag af en log...

  • 0
  • 0
#41 Eskild Nielsen

Problemet er jo, at hvis jeg i ODF læser specifikationen af anvendelse af datoer, så er bla. tidszoner tilladte - og det kunne jeg som implementør så finde på at putte i mine ODF-filer.

... men der er ikke en eneste ODF-applikation, der understøtter dette - de ignorerer alle tidszonen, når de loades. Derfor hæmmes interop i ODF-verdenen (på dette område), hvis jeg følger spec - for den følger ikke den verden specifikationen anvendes i.

Øh... Hæmmer interop?

Jeg læser det du skriver, som at ODF standarden tillader at man medtager dele af ISO8601 angivelsen, udover de basale dato+tid.

Applikationerne ved at de kan forekomme og er derfor parat til at ignorere dem.

Applikationerne ved også at det er lovligt ikke at medtage dem, og crasher derfor ikke hvis de mangler.

Og så vidt jeg forstår, så er enigheden i orden så langt?

Er forskellen så, at anbefalingen til ODF udviklere er 'persister de felter du kan persistere, uanset om du kan bruge dem', hvorimod anbefalingen til OOXML udviklere er 'persister kun de data, du kan bruge - dvs dato+tid'?

Og begge dele er anbefalinger, for i begge tilfælde skal man være forberedt på at modtage alt, intet og midt i mellem?

  • 0
  • 0
#42 Jesper Lund Stocholm Blogger

Hej Claus (og andre),

legalisering af klamphuggeri fra fortiden

Hvad mener du med dette? Hvis du hentyder til Microsoft og dens opførsel, så understøtter Microsoft Office ikke pt. skrivning af ISO-datoer i regneark.

Er det en legalisering?

Meget morsomt - det gør jeg nok heller ikke, men meget ofte bruger man regneark til at kommunikere diverse uddrag af en log...

Jæs - men uanset kontorpakke og dokumentformat, så fjernes tidszonen fra datoerne.

  • 0
  • 0
#45 Jesper Lund Stocholm Blogger

Hej Michael,

De opfandt noget nyt, nemlig at udelade tidszonen. For xmlschema-2 dateTime[0] er timezone obligatorisk

Det er da vist ikke korrekt?

Der står i din henvisning for datetime, at:

[i]The ·lexical space· of dateTime consists of finite-length sequences of characters of the form: '-'? yyyy '-' mm '-' dd 'T' hh ':' mm ':' ss ('.' s+)? (zzzzzz)?, where

* '-'? yyyy is a four-or-more digit optionally negative-signed numeral that represents the year; if more than four digits, leading zeros are prohibited, and '0000' is prohibited (see the Note above (§3.2.7); also note that a plus sign is not permitted);  
* the remaining '-'s are separators between parts of the date portion;  
* the first mm is a two-digit numeral that represents the month;  
* dd is a two-digit numeral that represents the day;  
* 'T' is a separator indicating that time-of-day follows;  
* hh is a two-digit numeral that represents the hour; '24' is permitted if the minutes and seconds represented are zero, and the dateTime value so represented is the first instant of the following day (the hour property of a dateTime object in the ·value space· cannot have a value greater than 23);  
* ':' is a separator between parts of the time-of-day portion;  
* the second mm is a two-digit numeral that represents the minute;  
* ss is a two-integer-digit numeral that represents the whole seconds;  
* '.' s+ (if present) represents the fractional seconds;  
* zzzzzz (if present) represents the timezone (as described below).[/i]

Læg mærke til sidste punkt.

  • 0
  • 0
#46 Claus Bruun

"Hvad mener du med dette? Hvis du hentyder til Microsoft og dens opførsel, så understøtter Microsoft Office ikke pt. skrivning af ISO-datoer i regneark.

Er det en legalisering?"

Jeg mener, at der har været lavet så mange dårlige forsøg på at implementere datoer helt generelt gennem tiden, som har givet kæmpe problemer.

Når I så laven en ny standard ville det være jævlens rart, om I lærte af fortiden og lavede noget, der kunne bruges til noget. Og der skal I turligvis se ud over egen næsetip, så OOXML bruger præcis samme standard, som resten. På sigt ville det jo være rart om der var een fungerende datostandard på tværs af alt.

  • 0
  • 0
#47 Jesper Lund Stocholm Blogger

Hej Claus,

Jeg mener, at der har været lavet så mange dårlige forsøg på at implementere datoer helt generelt gennem tiden, som har givet kæmpe problemer.

Vi skal ikke implementere datoer i OOXML - ligesom man heller ikke har gjort det i ODF. Så debatten om skudsekunder, skudår, gregorianske kalendre, "13-days dilemmaet" fra England og lignende er totalt out of scope. Det eneste vi skal er at være skarpe på at specificere, hvordan en givet dato persisteres i dokumentet.

Når I så laven en ny standard ville det være jævlens rart, om I lærte af fortiden og lavede noget, der kunne bruges til noget. Og der skal I turligvis se ud over egen næsetip, så OOXML bruger præcis samme standard, som resten. På sigt ville det jo være rart om der var een fungerende datostandard på tværs af alt.

Blot en klargørelse: vi er ikke ved at lave en ny standard. Vi er ved at rette teksten til i OOXML, så den bliver bedre.

Anyway - vi gør [b]præcist[/b] hvad du efterspørger - nemlig danner en profil af ISO-8601. Der er INTET i vores arbejde, der gør datoerne ikke-ISO-8601-valide. Prøv at se på oversigten i billedet herover. ISO-8601 er så omfattende, at det er bydende nødvendigt at profilere den til det formål man anvender den til. Det er nøjagtig det samme man har gjort med JavaScript profile, xsd:datetime profilen, SQL timestamp profilen og lignende.

Det er helt fair, at I mener, at tidszoner skulle med i profilen (selvom vi er uenige), men at gøre selve profileringen til et principielt problem er så tåbeligt, at det fortjener at blive ignoreret ihjel.

  • 0
  • 0
#48 Jesper Lund Stocholm Blogger

Hej Eskild,

Jeg læser det du skriver, som at ODF standarden tillader at man medtager dele af ISO8601 angivelsen, udover de basale dato+tid.

ODF tillader, at man anvender hele W3C Schema date/datetime profilen af ISO-8601.

Applikationerne ved at de kan forekomme og er derfor parat til at ignorere dem.

Applikationerne ved også at det er lovligt ikke at medtage dem, og crasher derfor ikke hvis de mangler.

Hvis bare det var så vel.

Applikationerne crasher ikke - men de regner forkert.

Det lyder som om, at du mener, at det er fint at ignorere tidszoneangivelser, men det kan jo have store konsekvenser.

Forestil dig, at jeg har to celler i et ODF-regneark med værdierne:

2010-12-31 og 2010-12-30

Når jeg trækker dem fra hinanden, så får jeg værdien 1

Forestil dig, at jeg har to celler i et ODF-regneark med værdierne:

2010-12-31T12:00:00 og 2010-12-31T11:51:00

Når jeg trækker dem fra hinanden, får jeg værdien 00:09:00

Forestil dig, at jeg har to celler i et ODF-regneark med værdierne:

2010-12-31T12:00:00+01 og 2010-12-31T11:51:00+00

Når jeg trækker dem fra hinanden, får jeg værdien 00:51:00

Du antyder, at det er OK, hvis man blot ignorerer tidszone-angivelsen - men det vil jo betyde, at værdien i regnearket i stedet for 00:51:00 ville blive 00:09:00 .

Hvis jeg i øvrigt putter tidszone-angivelserne med i et ODF-regneark og indlæser det i OOo Calc, så konverteres begge værdier til 9999-12-31 og dermed bliver forskellen på 00:00:00 .

Der er masser af tilfælde, hvor det er helt fint blot at ignorere de ting, som man ikke forstår - men i dette tilfælde er det totalt no-go, for regnearket vil regne forkert. Og derfor hæmmes ODF-interop på dette område, for eftersom der intet står i spec om indsnævringen af datoanvendelse, så er jeg nødt til at teste min applikation og de dokumenter den danner på tværs af alle applikationer. og selv da kan jeg ikke være sikker på, at jeg ikke har været "heldig" og ramt et vel-implementeret område. Idéen med en standard er da for pokker, at man ikke skal teste alle applikationer i verden for at sikre, at ens applikation kan udveksle data med dem. Man skal kunne tage standarden i hånden og med den have en rimelig forventning om, at den dækker anvendelsesområdet.

Er forskellen så, at anbefalingen til ODF udviklere er 'persister de felter du kan persistere, uanset om du kan bruge dem', hvorimod anbefalingen til OOXML udviklere er 'persister kun de data, du kan bruge - dvs dato+tid'?

Og begge dele er anbefalinger, for i begge tilfælde skal man være forberedt på at modtage alt, intet og midt i mellem?

Der er reelt ingen anbefaling i ODF udover "brug xsd:datetime". Anbefalingen i OOXML vil mere være i retning af "Hvis du ønsker at sikre maksimal interop med andre applikationer, så gem datoer i regneark uden tidszoneangivelse".

I øvrigt:

OOXML understøtter jo to "epocs" eller "null-datoer". Kunne følgende formulering være en mulighed for profilering af ISO-8601?

[i]Date is a subtype of Number. Date is represented by an integer value. A serial date is the expression of a date as the number of days elapsed from a start date called the epoch. Evaluators shall support all dates from 1904-01-01 through 9999-12-31 (inclusive) in calculations, should support dates from 1899-12-30 through 9999-12-31 (inclusive) and may support a wider date range. Note: Using expressions that assume serial numbers are based on a particular epoch may cause interoperability issues. Evaluators shall support positive serial numbers. Evaluators may support negative serial numbers to represent dates before an epoch. Note: It is implementation-defined if the year 1900 is treated as a leap year. Note: Evaluators that treat 1900 as a non-leap year can use the epoch date 1899-12-30 to compensate for serial numbers that originate from evaluators that treat 1900 as a leap year and use 1899-12-31 as an epoch date.[/i] Her tager vi hensyn til de konkrete epocs og kræver kun, at datoer understøttes [b]efter[/b] disse null-dates. Det gør jo det hele meget nemmere for implementeringerne ikke at skulle tage hensyn til "negative datoer". Vi specificerer jo så også (på tværs af Transitional og Strict), at nogle datoer måske er dannet af regneark, der opfatter 1900 som et skudår. Vi undgår så også helt at nævne anvendelse af tidszoner.

?

Og en sidste ting: jeg sad på vej i toget på arbejde og kiggede i ODF, og jeg har fundet ud af, hvorfor ingen applikationer baseret på ODF understøtter nogen form for tidszoner. Det kan simpelthen ikke lade sig gøre pga manglende tidszone-angivelse af den anbefalede basis-epoc.

  • 0
  • 0
#50 Michael Rasmussen
  • zzzzzz (if present) represents the timezone (as described below).

Ja, men det skyldes det forhold, at såfremt tidszone ikke fremgår, er det local timezone. Tilsvarende kan man også postfixe tiden med Z, hvilket indikerer, at tiden skal læses som UTC.

Så for at vende tilbage til dit indlæg. Jo, dataTime skal angives med timezone, men man har defineret til "shortcuts": localtime kan angives uden timezone, og UTC kan angives med postfix Z.

Fra xmlschema-2: "[Definition:] dateTime values may be viewed as objects with integer-valued year, month, day, hour and minute properties, a decimal-valued second property, and a boolean timezoned property. Each such object also has one decimal-valued method or computed property, timeOnTimeline, whose value is always a decimal number; the values are dimensioned in seconds, the integer 0 is 0001-01-01T00:00:00 and the value of timeOnTimeline for other dateTime values is computed using the Gregorian algorithm as modified for leap-seconds. The timeOnTimeline values form two related "timelines", one for timezoned values and one for non-timezoned values. Each timeline is a copy of the ·value space· of decimal, with integers given units of seconds."

Så jo, dateTime skal angives med timezone. Enten implicit som localtime, der vel og mærke internt repræsenteres som UTC, eller eksplicit som UTC. Deraf "[..]a boolean timezoned property".

  • 0
  • 0
#51 Jesper Lund Stocholm Blogger

Hej Michael,

Så jo, dateTime skal angives med timezone. Enten implicit som localtime, der vel og mærke internt repræsenteres som UTC, eller eksplicit som UTC.

Jeg synes ikke, at det er voldsomt relevant for denne diskussion, men jeg vil da gerne lege med :o)

Jeg er ikke enig i din fortolkning af tekstten omkring tidszoner og specielt "local time". "Local time" er ikke et generisk udtryk men et udtryk, der har en specifik mening. I ISO-8601 sammenhænge er "local time" det samme som "uden tidszone". Det står faktisk lidt senere i den tekst du citerede fra:

"Local" or untimezoned times are presumed to be the time in the timezone of some unspecified locality as prescribed by the appropriate legal authority"

At "local time" implicit skulle indebære en tidszoneangivelse og internt repræsenteret i UTC-tid er for mig noget volapyk - når man læser hele teksten og ikke kun det brudstykke du citerede.

Hvor blev de andre i øvrigt af? Forstå mig ret - det er da rart at kunne gøre rent bord en gang imellem - men det var da fesent sådan som de pludseligt stak halen imellem benene.

:o)

  • 0
  • 0
#52 Poul-Henning Kamp Blogger

Hvor blev de andre i øvrigt af? Forstå mig ret - det er da rart at kunne gøre rent bord en gang imellem - men det var da fesent sådan som de pludseligt stak halen imellem benene.

Hvis det er mig du hentyder til, så har jeg sagt hvad der er at sige: I er ved at lave noget klamp og det bør I lade være med og istedet henvende jeg til nogen der har forstand på tid, datoer og kalendrer.

Poul-Henning

  • 0
  • 0
#53 Michael Mortensen

Jeg mener faktisk, at Jesper og de andre folk bag OOXML har gjort et godt stykke arbejde.

Efter at have læst det meste af tråden igennem påny, så bliver jeg faktisk irriteret og forstyrret af Poul-Henning's mere og mere infantile udtalelser, hvor folk som Jesper kæmper forgæves.

Jeg kender ikke Jesper, men jeg kan læse han brænder for det han laver, han har dyb indsigt i udfordringerne og han har en praumatisk tilgang til løsningsforslaget.

Du får en +1 i min bog for at holde niveauet professionelt (man kan mærke din faglige stolthed) og nuanceret.

  • 0
  • 0
#54 Venligst Slet Min Bruger

Jeg må erklære mig helt enig Michael.

Jeg kender ikke ret meget til teknikken bag dokumentformater, men det irriterer mig voldsomt, at en intelligent mand som PHK (åbenbart) ikke kan argumentere uden at skulle falde til børnehaveniveau. Det klæ'r så absolut ikke en voksen mand.

  • 0
  • 0
#55 Claus Agerskov

At give mulighed for brug af tidszone for tidspunkter vil gøre det muligt at udvikle forbedrede applikationer, som benytter disse dokumentstandarder.

Hvis de applikationer, som ikke understøtter tidszone, blot ignorerer denne, så er de lige så godt stillet, som uden en dokumentstandard med tidszone.

Mens de applikationer, som understøtter tidszone, vil give en forbedret brug af tidspunkter.

Med venlig hilsen Claus Agerskov, AgerCon

  • 0
  • 0
#56 Jesper Lund Stocholm Blogger

Hej Claus,

(jeg har flyttet lidt rundt på indholdet af dit indlæg)

Hvis de applikationer, som ikke understøtter tidszone, blot ignorerer denne, så er de lige så godt stillet, som uden en dokumentstandard med tidszone.

Claus, det er på ingen måde korrekt. Du undervurderer fuldstændigt konsekvenserne af at "ignorere" eventuelle tidszoner. Det drejer sig jo ikke om, at en værdien

2010-10-01T19:49:45+01

blot vises som

2010-10-01T19:49:45

Det drejer sig om, at alle beregninger på dette tidspunkt bliver forkerte!

Derfor er det bydende nødvendigt, at der er enighed i økosystemet om, hvordan tidspunkter håndteres. Det nytter ikke noget, at der er nogen, der begynder at eksperimentere med dette og danne informationer, som resten af økosystemet ikke kan håndtere.

At give mulighed for brug af tidszone for tidspunkter vil gøre det muligt at udvikle forbedrede applikationer, som benytter disse dokumentstandarder. (...) Mens de applikationer, som understøtter tidszone, vil give en forbedret brug af tidspunkter.

Det er IKKE løsningen blot at begynde at skrive data i cellerne, som resten af økosystemet ikke kan håndtere. Jeg er helt med på, at det er nødvendigt, at man kan udvikle forbedrede applikationer. Men det skal ikke ske ved blot at begynde at skrive tidszoner med datoerne.

I stedet skal det ske via de udvidelsesmekanismer vi har i OOXML - også kendt som MCE. ODF har desværre ikke en lignende funktionalitet, så her er man desværre ilde stedt ifht indførsel af tidszoner (som ikke kan anvendes i ODF i dag). MCE er [b]præcist[/b] dannet for at håndtere disse ting, og MCE giver mulighed for, at man kan skabe innovation og samtidig sikre, at andre applikationer stadig kan fungere. [b]DET[/b] er måden at indføre tidszoner på - og ikke blot at begynde at forurene økosystemet.

Når man så har fået nogle erfaringer med at anvende tidszoner på tværs af applikationerne, så er man velkommen til at lægge tingene på bordet hos os i ISO og så er jeg sikker på, at vi vil se på det med stor velvilje.

  • 0
  • 0
#58 Maciej Szeliga

Det giver bagslag på sigt, forstil jer at skulle regne med PI=3,1 fordi udstyret kun kan håndtere 1 decimal. Tid skal altid internt lagres på en eller anden absolut og veldefineret måde, inkl. tidszone og sommertid (Moskva-tid er ikke det samme som Berlins sommertid selv om det ser ud af det samme), hvordan tiden så bliver vist er op til applikationen eller feltdefinitionen. Kan applikationerne ikke håndtere det så må de patches, det nytter ikke at prøve at patche virkeligheden. Prøv f.eks. at tænke tilbage på det forholdsvis nyligt overståede år 2000 som netop var en løsning på et problem som aldrig burde være opstået hvis man havde tænkt sig om fra starten.

  • 0
  • 0
#59 Erik Cederstrand

Claus, det er på ingen måde korrekt. Du undervurderer fuldstændigt konsekvenserne af at "ignorere" eventuelle tidszoner. Det drejer sig jo ikke om, at en værdien

2010-10-01T19:49:45+01

blot vises som

2010-10-01T19:49:45

Det drejer sig om, at alle beregninger på dette tidspunkt bliver forkerte.

Vis mig en beregning i et tænkt program, som understøtter tidszoner, som bliver forkert.

Og vis mig så en beregning i et tænkt program, som ikke understøtter tidszoner, som bliver forkert.

Det sidste vil jo blot svare til et program, som understøtter tidszoner, men kun understøtter UTC.

Vi er ved at planlægge mødet i Beijing i december, og her kunne en oversigt over agendaen for dag 1 se således ud:

Jesper 08:30 - 10:00 Thorsten 10:15 - 11:45 Gareth 13:00 - 14:30

Hvis jeg tamper disse ind i et regneark - hvad forestiller du dig så, at der skal ske?

På indtastningstidspunktet i Danmark? På åbningstidspunktet i Japan, i USA, i England?

I programmet uden tidszoneunderstøttelse er du på røven ligesom programmerne i dag. Du kan ikke planlægge et globalt telefonmøde uden at kommunikere tidszonen ad andre kanaler.

I programmet, som understøtter tidszoner, vil det tvinge dig til at tage stilling til tidszonen på indtastningstidspunktet. I dokumentformatet vil det gemme tidspunktet omregnet til UTC. I den senere visning hos José i Peru kan programmet være flink at vise tidspunktet i Josés lokale tid (inkl. evt. sommertid).

  • 0
  • 0
#60 Jesper Lund Stocholm Blogger

Hej Erik,

Vis mig en beregning i et tænkt program, som understøtter tidszoner, som bliver forkert.

Og vis mig så en beregning i et tænkt program, som ikke understøtter tidszoner, som bliver forkert.

Dette drejer sig ikke om, hvad tænkte programmer gør - det drejer sig om, hvad virkelige programmer gør, og hvordan vi bedst muligt sikrer interop imellem dem.

Hvis nogen gerne vil have tidszoner i deres regneark, så er de mere end velkomne til det - men de skal bør have så meget respekt for det eksisterende økosystem, at de bruger de mekanismer i OOXML, der er lavet specifikt til udvidelser - nemlig MCE.

  • 0
  • 0
#62 Erik Cederstrand

Dette drejer sig ikke om, hvad tænkte programmer gør - det drejer sig om, hvad virkelige programmer gør, og hvordan vi bedst muligt sikrer interop imellem dem.

Og den interop kan fint lade sig gøre ved at definere, at datoer i OOXML dokumentformatet gemmes i UTC datoer. Nuværende programmer kan køre videre som de har lyst, lykkeligt uvidende om, at et klokkeslet ikke giver mening i global sammenhæng uden angivelse af tidszone. Fremtidige programmer, eller fremtidige versioner af eksisterende programmer, kan vælge at understøtte tidszoner i GUI'en og i dato-beregninger.

Så længe datoer gemmes i formatet uden tidszone, og der i afsnit 32.17.234 i dokumentationen står, at datoer er UTC, så er der fin bagud-kompatibilitet.

Jeg forstår ikke, hvorfor du gør det så svært. Og jeg må tilslutte mig PHK her, jeg forstår ikke, hvorfor I specifikt vil hindre programmer i at understøttelse tidszoner.

  • 0
  • 0
#63 Jesper Lund Stocholm Blogger

Hej Erik,

Jeg forstår ikke, hvorfor du gør det så svært. Og jeg må tilslutte mig PHK her, jeg forstår ikke, hvorfor I specifikt vil hindre programmer i at understøttelse tidszoner.

Vær opmærksomme på, at dette ikke er en akademisk øvelse i, hvordan verden ønskeligt kunne se ud, hvis alt var muligt. Det er et pragmatisk forsøg på at sikre det bedst (tekniske) udgangspunkt sammenholdt med, at specifikationen bliver anvendelig for det økosystem den skal anvendes i.

For ODF drejer dette sig bla. om, at der er et eksisterende økosystem, hvor ingen implementeringer i dag understøtter anvendelse af tidszoner. Hvis man i ODF eksplicit beskrev tilladelse af tidszoner, så ville dokumenter skrevet på baggrund af den ikke kunne fungere i økosystemet. Eksempelvis understøtter OpenOffice.org ikke tidsangivelse i UTC. Det drejer sig ikke om, at UTC-angivelsen ignoreres - den regner/parser ganske enkelt forkert.

For brugerne af ODF (både i ODF TC, Dansk Standard, ISO og de "almindelige" brugere), synes der heller ikke at være et behov for tidszoner i regneark. På OpenOffice.orgs lister over mest ønskede feature-requests fremkommer den ikke engang på de tyve første pladser.

Det drejer sig om bagudkompatibilitet.

Jeg vil foreslå dig at undersøge, hvor mange af ændringerne i ODF fra ODF 1.1 til ODF 1.2, der direkte smadrer bagudkompatibilitet med applikationer, der understøtter ODF 1.0/1.1 . Mig bekendt er der én - og det vel at mærke i en specifikation, der er vokset med næsten 100% imellem version 1.1 og 1.2 . Det er jo ikke et tilfælde. For samtidig med, at man tilføjer ny funktionalitet i ODF, så sikrer man samtidig, at eksisterende funktionalitet ikke ændres, så programmer, der understøtter en tidligere version stadig fungerer.

For den eksisterende feature i ODF, der er blevet ændret, så skyldtes det, at man oprindeligt havde lavet en ufleksibel måde at gøre det på (justering i rammer, svjh), og alle omkring bordet havde et ønske om at få det ændret. Men for tidszoner forholder det sig ikke på den måde - og derfor kan de ikke i dag anvendes i ODF. Der er INGEN, der har ønsket det - hverken standardiseringseksperterne, leverandørerne eller brugerne. Mig bekendt er det kun jer tre-fire stykker i debatforummet på Version2, der insisterer på at få det med (sandsynligvis uden nogensinde at komme til at anvende det selv).

... og undskyld mig - men det er altså ikke nok.

jeg forstår ikke, hvorfor I specifikt vil hindre programmer i at understøttelse tidszoner.

[b]Der er ingen, der forhindrer en implementering i at understøtte tidszoner i regneark[/b]. Både ODF og OOXML har funktionalitet til at understøtte sådan en udvidelse af featuresættet, så de kan passende benyttes til det.

  • 0
  • 0
#64 Lars Lundin

Som jeg læser ISO-8601 afsnit 3.2.1, så er 30-02-1712 ikke en valid ISO-8601 dato.

Du har ret, ISO-8601 definerer kun datoer i den gregorianske kalender.

Konsekvensen er, at for Danmark kan ISO-8601 kun bruges fra 1700-03-01, mens den kun kan bruges for Sverige fra 1753-03-01.

Så min "syretest" er ikke relevant her - undskyld støjen.

PS. For ikke-gregorianske datoer foretrækker jeg stadig formatet YYYY-MM-DD.

  • 0
  • 0
#65 Erik Cederstrand

Hvis man i ODF eksplicit beskrev tilladelse af tidszoner, så ville dokumenter skrevet på baggrund af den ikke kunne fungere i økosystemet.

Jeg foreslår ikke, at man i dokumentformatet skal kunne gemme "2007-04-05T14:30:23+05:30". Jeg foreslår ikke engang, at man skal kunne gemme "2007-04-05T14:30:23Z" (UTC). Jeg foreslår, for at sikre bagudkompabilitet, at man blot skal skrive "2007-04-05T14:30:23", og at I i dokumentationen skriver, at datoer implicit forstås som "2007-04-05T14:30:23Z".

Altså, nuværende programmer kan vælge at beholde det nuværende niveau af dato-understøttelse. Fremtidige versioner vil kunne vælge at tilbyde understøttelse af tidszoner, så længe de opfatter datoer hentet fra et dokument som værende i UTC, og sørger for at omregne datoer til UTC, når de gemmes i dokumentet.

Eksempelvis understøtter OpenOffice.org ikke tidsangivelse i UTC. Det drejer sig ikke om, at UTC-angivelsen ignoreres - den regner/parser ganske enkelt forkert.

Jeg savner stadig et eksempel på, at OpenOffice (eller Excel) regner forkert.

  • 0
  • 0
#66 Jesper Lund Stocholm Blogger

Hej Erik,

Jeg foreslår, for at sikre bagudkompabilitet, at man blot skal skrive "2007-04-05T14:30:23", og at I i dokumentationen skriver, at datoer implicit forstås som "2007-04-05T14:30:23Z".

Det vil være i modstrid med ISO-8601. ISO-8601 angiver, at tidsangivelse uden tidszone eller UTC-angivelse) fortolkes som "local". ISO-8601 tillader ikke (som jeg læser den) konvertering den anden vej.

Jeg savner stadig et eksempel på, at OpenOffice (eller Excel) regner forkert.

Lav et regneark i Calc med en celle med en dato i - fx 31-12-2010 12:59 og sørg for, at cellen er formatteret som en dato. Gå herefter ind i den XML-stream i ODS-pakken, der hedder "content.xml". og tilføj et "Z" til dato-stemplet.

Når regnearket loades ændres datoen til 31-12-9999.

  • 0
  • 0
#67 Erik Cederstrand

ISO-8601 angiver, at tidsangivelse uden tidszone eller UTC-angivelse) fortolkes som "local"

Tak for ovenstående, og for eksemplet. Nu er jeg med på, hvad du mener, og hvorfor det ikke er så nemt, som det ser ud.

Måske kan det løses med en one-liner, så de nuværende programmer i det mindste accepterer et "Z", uden i øvrigt at gøre noget ved det.

  • 0
  • 0
#68 Jesper Lund Stocholm Blogger

Hej Erik,

Altså, nuværende programmer kan vælge at beholde det nuværende niveau af dato-understøttelse. Fremtidige versioner vil kunne vælge at tilbyde understøttelse af tidszoner, så længe de opfatter datoer hentet fra et dokument som værende i UTC, og sørger for at omregne datoer til UTC, når de gemmes i dokumentet.

Der er også andre forhold, der taler imod angivelse af tidszoner.

Tidsangivelser konverteres i runtime i til serial values og anvendes herefter i bla. funktioner. Når du kun har ét tal at gøre godt med - hvordan vil du så kende forskel på kl. 11:00 i London og kl. 12:00 i København? Hvis du derfor vil have tidszoner med i, så skal der også defineres nye funktioner, der kan regne med disse tidszoner og have dem med som argumenter (eller anden vis).

I det øjeblik man starter at tænke på anvendelse af tidszoner i regneark, så bliver det hurtigt ekstremt komplekst. for løsningen skal være dækkende for al funktionalitet i regneark. Der er indtil nu ikke nogen, der har vurderet, at det ville give nok værdi at starte på dette arbejde - i forhold til den opnåede værdi for deres brugere.

Så jeg/vi vil velkomme ethvert gennemarbejdet forslag til anvendelse af tidszoner i regneark - det er 112% sikkert.

... men det skal være af større værkshøjde end "Tillad tidszoner - alt andet er noget klamhuggeri".

Jeg vil gerne understrege igen, at der ikke er nogen, der forhindrer nogen i at anvende tidszoner i deres regneark. Men de bør bruge de udvidelsesmuligheder, der er i dokumentformaterne til det - alt andet er at spille hazard med det eksisterende økosystem.

  • 0
  • 0
#69 Erik Cederstrand

Tidsangivelser konverteres i runtime i til serial values og anvendes herefter i bla. funktioner. Når du kun har ét tal at gøre godt med - hvordan vil du så kende forskel på kl. 11:00 i London og kl. 12:00 i København?

Tadaa, du rammer hovedet på sømmet. Det er det her, I vil videreføre i den kommende version af dokumentformatet - ét tal, som hverken giver mening i London eller København.

Eksisterende programmer lader i forvejen brugerne i stikken, ikke noget nyt der. Til gengæld har diverse programmeringssprog, bl.a. Java og C#, i et årti fint kunnet konvertere og beregne med datoer med tidszoner, så større er problemet heller ikke, uanset den interne repræsentation af dato-værdien.

Så jeg/vi vil velkomme ethvert gennemarbejdet forslag til anvendelse af tidszoner i regneark - det er 112% sikkert.

... men det skal være af større værkshøjde end "Tillad tidszoner - alt andet er noget klamhuggeri".

Jeg tror du blander tingene sammen. Jeg (vi) vil bare give mulighed for at gemme datoer som UTC i [b]dokumentet[/b].

Ingen her har krævet, at nuværende [b]programmer[/b] i morgen indfører understøttelse af visning af, og beregning med, datoer med tidszone, og jeg er fuldt bevidst om, at det ikke vil være nemt at gøre (og gøre brugervenligt). Det er datoer i 'local time' i dokumentformatet, som jeg gætter PHKs 'klamhuggeri' hentyder til, ikke Calcs eller Excels nuværende understøttelse tidszoner.

  • 0
  • 0
#70 Jesper Lund Stocholm Blogger

Hej Erik,

Tadaa, du rammer hovedet på sømmet. Det er det her, I vil videreføre i den kommende version af dokumentformatet - ét tal, som hverken giver mening i London eller København.

Jeps - og det "tal" er hvad der i ISO-8601 sammenhænge hedder "local time". Der er ikke noget hokuspokus i det. Anvendelsen er [b]præcist[/b], hvad brugerne forventer.

Eksisterende programmer lader i forvejen brugerne i stikken, ikke noget nyt der.

Brugerne lades ikke i stikken - for ODFs opførsel er [b]præcist[/b] som de forventer det. Når en bruger tamper 12:00 ind i en celle i et regneark i Calc, så forventer denne, at han blot gemmer "kl. 12:00" uden tidszoneangivelse.

Hvis vi skal lave noget så fundamentalt om som angivelse af tid i regneark, så skal der være et behov for det, der er stort nok til at retfærdiggøre det. Hvis du spørger Microsoft, så er der ingen af deres kunder, der efterspørger det. Hvis du spørger Appel, Novell, ORACLE og andre, så er svaret nøjagtigt det samme. I den samlede pulje af bugs/feature-requests for OOo er det maksimalt blevet nævnt 5 gange. Der ER ikke noget behov for tilføjelse af dette:

Det har tidligere været oppe at vende i ODF-sammenhænge, og dengang sagde Rob Weir:

"Yes, you are talking about users. But I am thinking about users, and if their implementations suddenly started changing date-dependent financial calculations when their spreadsheet was emailed from Boston to LA, then chaos would ensue. There is a 20-year convention in this area, with firm user expectations in how this works. We're not going to change this in ODF 1.2."

Til gengæld har diverse programmeringssprog, bl.a. Java og C#, i et årti fint kunnet konvertere og beregne med datoer med tidszoner, så større er problemet heller ikke, uanset den interne repræsentation af dato-værdien.

Og det eksisterende økosystem af biblioteker og sprog rundt omkring er netop en grund til ikke at redefinere/ændre betydningen ad ISO-8601. Der er nok steder i ODF, hvor man har "genbrugt" (læs: skamredet) en eksisterende standard, påstået at man har genbrugt den men i realiteten refineret funktionaliteten, så den stemmer overens med opførslen i OOo. Vi skal ikke ud i det igen.

Jeg tror du blander tingene sammen. Jeg (vi) vil bare give mulighed for at gemme datoer som UTC i dokumentet.

Og den mulighed har du allerede - og endda på en måde, hvor du ikke ødelægger alt og alle. Hvis du laver en celle i et regneark i ODF, så kunne den se således ud:

[code=xml]

31-12-10 12:59
[/code]

Det eneste du behøver er at tilføje din egen attribut til elementet, fx som

[code=xml]

31-12-10 12:59 (UTC)
[/code] Så er du kørende.

  • 0
  • 0
Log ind eller Opret konto for at kommentere