---

Jeg har brug for lidt hjælp til datoberegniner. Specifikt gælder det
addition af måneder:

Hvad er

29/1 +1 måned (etc)
28/1 + 1 måned+1 dag (etc)
29/2 + 1 år
31/8 + 1 måned


Jeg har læst på ISO 8601 og har fundet mindst 2 svarmuligheder:

ENTEN at lægge måneden til, hvis der ikke er dage nok, går man tilbage til
første mulige dag. Altså en end-of-month metode.

Ex. 31/8 + 1 månede er 30/9
http://www.timeanddate.com/date/dateadded.html?d1=31&m1=08&y1=2008
&type=add&ay=&am=1&ad=+&aw=+



ELLER at tage det nødvendige antal måneder i næste måned, som excel gør det
=DATE(YEAR(D4);MONTH(D4)+1;DAY(D4)) = 01.10.


Hvad er "korrekt", er de begge, og hvad hedder så de forskellige standarder
? Jeg antager selv at den ene (excels) er baseret på absolute julian day
number, og derefter konverteret tilbage.


Jeg har ikke prøve Perl eller PHPs datomoduler endnu.

Mvh

Torben

---

"T" <myicqKATTE@bakkegmx.net> wrote in message
news:Xns9A9D6C404E6F8myicqKATTEbakkegmxne@62.243.74.163...
>
> ENTEN at lægge måneden til, hvis der ikke er dage nok, går man tilbage til
> første mulige dag. Altså en end-of-month metode.

Hvis man 12 gange lægger en måned til, forventer man måske at have lagt et
helt år til, men der bliver man så snydt, hvis startdatoen er >28.

>
> Hvad er "korrekt", er de begge

Der er nok ikke noget korrekt svar. Måneder er simpelthen ikke ensartede
nok. Selv årene er jo ikke lige lange.

---

"Uffe Kousgaard" <oh@no.no> skrev i meddelelsen
news:48295d10$0$90272$14726298@news.sunsite.dk...
> "T" <myicqKATTE@bakkegmx.net> wrote in message
> news:Xns9A9D6C404E6F8myicqKATTEbakkegmxne@62.243.74.163...
>>
>> ENTEN at lægge måneden til, hvis der ikke er dage nok, går man tilbage
>> til
>> første mulige dag. Altså en end-of-month metode.
>
> Hvis man 12 gange lægger en måned til, forventer man måske at have lagt et
> helt år til, men der bliver man så snydt, hvis startdatoen er >28.
>
>>
>> Hvad er "korrekt", er de begge
>
> Der er nok ikke noget korrekt svar. Måneder er simpelthen ikke ensartede
> nok. Selv årene er jo ikke lige lange.


Og så har du ikke nævnt skudsekundet, som ikke engang er helt forudsigeligt.
Det nylige jordskælv i Kina har måske flyttet det lidt.

Mvh
Martin

---

Uffe Kousgaard wrote:
> "T" <myicqKATTE@bakkegmx.net> wrote in message
> news:Xns9A9D6C404E6F8myicqKATTEbakkegmxne@62.243.74.163...
>>
>> ENTEN at lægge måneden til, hvis der ikke er dage nok, går man
>> tilbage til første mulige dag. Altså en end-of-month metode.
>
> Hvis man 12 gange lægger en måned til, forventer man måske at have
> lagt et helt år til, men der bliver man så snydt, hvis startdatoen er
> >28.
>
>>
>> Hvad er "korrekt", er de begge
>
> Der er nok ikke noget korrekt svar. Måneder er simpelthen ikke
> ensartede nok. Selv årene er jo ikke lige lange.

Enig.

Hvad der er korrekt må komme an på, hvad dit behov er.

Der kan ikke konstrueres nogen standard, der opfylder de to simple og
rimelige krav man kunne have:

(1) dag/måned + 1 måned = dag/(måned+1)
(2) dato + 1 måned + 1 måned + (12 gange) = dato + 1 år

Man kunne tilføje (dato + 1 måned) - 1 måned = dato, men jeg tror faktisk
ikke det giver nogen yderligere kompleksiteter.

Simple modeller er:
(a) dag/måned + 1 måned = dag/(måned+1), hvis dag ligger uden for (måned+1)
vælges sidste dag i (måned+1)
(b) dag/måned + 1 måned = dag/(måned+1), hvis dag ligger uden for (måned+1)
føres de overskydende dage ind i (måned+2).
(c) dato + 1 måned = dato + 30 dage
(d) dato + 1 måned = dato + #dage i indværende måned
(e) dato + 1 måned = dato + #dage i næste måned

(a) og (b) forsøger at opfylde (1) men kommer alligevel til kort når
månederne er korte.

(c) giver op og laver bare en helt simpel løsning.

(d) og (e) opfylder (2), men giver til gengæld hæslige resultater ift. (1):
e.g. 27. februar + 1 måned = 30. marts.

--
Venlig hilsen /Best regards
Kristian Damm Jensen

---

T wrote:
> Jeg har brug for lidt hjælp til datoberegniner. Specifikt gælder det
> addition af måneder:
>
> Hvad er
>
> 29/1 +1 måned (etc)
> 28/1 + 1 måned+1 dag (etc)
> 29/2 + 1 år
> 31/8 + 1 måned [..]
> ELLER at tage det nødvendige antal måneder i næste måned, som excel gør det
> =DATE(YEAR(D4);MONTH(D4)+1;DAY(D4)) = 01.10.
>
> Hvad er "korrekt", er de begge, og hvad hedder så de forskellige standarder
> ? Jeg antager selv at den ene (excels) er baseret på absolute julian day
> number, og derefter konverteret tilbage.
>
> Jeg har ikke prøve Perl eller PHPs datomoduler endnu.

Som de andre svar indikerer er der ikke noget der er oplagt korrekt
eller forkert, kun mere eller mindre hensigtsmæssige løsninger.
Epoke-tidsstempler (også populært kaldet unix-timestamps) indeholder
blot antal sekunder der er gået siden midnat 1970-01-01. Dermed er
aritmetikken ret ligetil. Alle invariante enheder (såsom sekund, minut,
time, dag og uge) er nemme at regne med og alle andre enheder (måned,
ugenummer og år) er noget man er nødt til at bruge specielle
konverteringsbiblioteker til. Dermed bliver det svært for en udvikler at
begå fejl fordi man forstår det bagvedliggende princip.

Den modsatte løsning er at bruge en slags datorepræsentation, hvor alle
tider skrives som "yyyy-mm-dd HH:MM:ss" (modulo diverse andre formater
og med den note at der ikke er tale om den interne repræsentation, men
den som udvikleren anvender). Her er alle enheder nemme at regne med og
udvikleren har igen nemt ved at forstå de underliggende principper.
Omkostningen er en noget tungere syntaks og potentielt ugyldige datoer
(f. eks. 2008-02-30), som fører til fejl.

Det værste du kan gøre er at sætte dig imellem to stole og beslutte at
man altid lægger en måned til på en bestemt måde (se Kristians liste).
Det kan kun føre til problemer, da udvikleren enten ikke forstår
konsekvenserene eller blot får brug for noget andet.

Mvh. Michael.

---

Michael Zedeler <michael@zedeler.dk> wrote in
news:CFlWj.17$ML6.9@news.get2net.dk:

> Som de andre svar indikerer er der ikke noget der er oplagt korrekt
> eller forkert, kun mere eller mindre hensigtsmæssige løsninger.

Tak for svarene.

Projektet er til en maskine der laver datostempling, og her vil kunderne
i "industrien" gerne typisk have udløbsdato = nuværende + (n) måneder, dvs
_måneden_ er vigtig.

Derfor bliver der nok 2 forskellige options:

a) end-of-month, hvor måneden bliver lagt til først. Hvis dagen ikke
findes, tages sidste gyldige dag i den måned.
   Svarer til excel        
       edate(2007-01-31;1) = 2007-02-28

b) normal, hvor næste dag(e) bliver brugt, hvis dato ikke findes.
   Svarer til excel
       date(day(31-1-07);month(31-1-07)+1;year(31-01-07)) = 03-03-07
Måske kunne denne funktion også hedde "serialized" da den jo regner
med en absolut værdi for alle tidspunkter.


Nogen som har bedre forslag til navnene ?

Mvh

Torben

---

T <dam-kat-jensen@gmail-kat-.com> writes:

> Michael Zedeler <michael@zedeler.dk> wrote in
> news:CFlWj.17$ML6.9@news.get2net.dk:
>
>> Som de andre svar indikerer er der ikke noget der er oplagt korrekt
>> eller forkert, kun mere eller mindre hensigtsmæssige løsninger.
>
> Tak for svarene.
>
> Projektet er til en maskine der laver datostempling, og her vil kunderne
> i "industrien" gerne typisk have udløbsdato = nuværende + (n) måneder, dvs
> _måneden_ er vigtig.

Jeg kan ikke forestille mig, at varer holder kortere tid, hvis de er
lavet i februar end, hvis de er lavet i marts, så den mest fornuftige
løsning må være at omregne 1 måned = 30 dage. Så er udlbsdatoen altid
det samme antal dage efter produktionsdatoen.

Hvis firmaerne af æstetiske årsager foretrækker samme dag i måneden
for udløbsdatoen som for produktionsdatoen, så brug en arbitrær regel,
når det ikke kan lade sig gøre -- hvis udløbsdatoerne alligevel er en
approksimation med flere dages usikkerhed, så betyder det ikke så
meget, om du runder 31/4 op til 1/5 eller ned til 30/4.

   Torben

---

"Torben "Ægidius" Mogensen" <torbenm@pc-003.diku.dk> wrote in message
news:7zve1hcmky.fsf@pc-003.diku.dk...
>T <dam-kat-jensen@gmail-kat-.com> writes:
>
>> Michael Zedeler <michael@zedeler.dk> wrote in
>> news:CFlWj.17$ML6.9@news.get2net.dk:
>>
>>> Som de andre svar indikerer er der ikke noget der er oplagt korrekt
>>> eller forkert, kun mere eller mindre hensigtsmæssige løsninger.
>>
>> Tak for svarene.
>>
>> Projektet er til en maskine der laver datostempling, og her vil kunderne
>> i "industrien" gerne typisk have udløbsdato = nuværende + (n) måneder,
>> dvs
>> _måneden_ er vigtig.
>
> Jeg kan ikke forestille mig, at varer holder kortere tid, hvis de er
> lavet i februar end, hvis de er lavet i marts, så den mest fornuftige
> løsning må være at omregne 1 måned = 30 dage. Så er udlbsdatoen altid
> det samme antal dage efter produktionsdatoen.
>
> Hvis firmaerne af æstetiske årsager foretrækker samme dag i måneden
> for udløbsdatoen som for produktionsdatoen, så brug en arbitrær regel,
> når det ikke kan lade sig gøre -- hvis udløbsdatoerne alligevel er en
> approksimation med flere dages usikkerhed, så betyder det ikke så
> meget, om du runder 31/4 op til 1/5 eller ned til 30/4.
>
> Torben

Jeg har også svært ved at se forskellen mellem 31/4 og 1/5 :)

the_mip

---

torbenm@pc-003.diku.dk (Torben Ægidius Mogensen) wrote in
news:7zve1hcmky.fsf@pc-003.diku.dk:

> Jeg kan ikke forestille mig, at varer holder kortere tid, hvis de er
> lavet i februar end, hvis de er lavet i marts, så den mest fornuftige
> løsning må være at omregne 1 måned = 30 dage. Så er udlbsdatoen altid
> det samme antal dage efter produktionsdatoen.
>
> Hvis firmaerne af æstetiske årsager foretrækker samme dag i måneden
> for udløbsdatoen som for produktionsdatoen, så brug en arbitrær regel,
> når det ikke kan lade sig gøre -- hvis udløbsdatoerne alligevel er en
> approksimation med flere dages usikkerhed, så betyder det ikke så
> meget, om du runder 31/4 op til 1/5 eller ned til 30/4.
>
> Torben


Nej, men det betyder noget for product managers i fødevareindustrien :)

Man har en dato som under udskrift formatteres [mm.yy] f.ex, men i
produktet er datoer altid exacte, da de kan linkes internt med forskellige
formater. Det betyder altså, at hvis den faktiske dato er 01.03.08 står
der en helt anden måned end 29.02.08.

På den baggrund - at formatteringen er mm.yy - skal der være begge
muligheder.


Ønsker fra producenter af fødevarer og lignende har mange og til tider
sære ønsker ang stemplingen af deres varer. Der er også dem som vil have
stemplingen krypteret, så der står "XVHFIJ" i stedet for 290208.


Så det var lige baggrundshistorien, off-topic.