Dato + 2,5 år

Du burde kunne nøjes med flg.:
$nydato = strtotime("+30 month", strtotime($gammeldato));

ikke hvis datoen er fra før 01-01-1970

Skal et halvt år være 365/2 dage eller bare 6 kalendermåneder?

6 kalendermåneder ...

function addyear($dato,$aar=1,$md=0){
  list($d,$m,$a)=explode('-',$dato);
  $a=$a+$aar;
  $m=$m+$md;
  while(12<$md){
    $md=$md-12;
    $a++;
  }
  if(31==$d && in_array($m, array(4,6,9,11)) $d=30;
  if(2==$m && 28<$d){
    $skud=false;
    if(0 == $a % 4) $skud=true;
    if(0 == $a % 100) $skud=false;
    if(0 == $a % 400) $skud=true;
    if(!$skud) $d=28;
  }
  if(10>$m) $d="0$m"; // tvinger måned til at være med to cifre
  return "$d-$m-$a";
}

Funktionen kan stadig bruges på de gamle måder:
$nydato = addyear("25-01-1855"); // lægger et år til
$nydato = addyear("25-01-1855", 2); // lægger to år til

Men nu er der en ny måde at kalde den:
$nydato = addyear("25-01-1855", 2, 6); // lægger 2 år og 6 måneder til
$nydato = addyear("25-01-1855", 0, 3); // lægger 3 måneder til

I tilfælde af at en beregnet dato overskrider længden på den beregnede måned, sættes den nye dato til sidste dag i måneden.

Et lidt anderledes bud:

$r = mysql_fetch_assoc(mysql_query("SELECT ADDDATE('2006-07-26', INTERVAL +18 MONTH) AS dato"));
echo $r['dato'];

Den kan også bruges til datoer før 1970.

Sandbox >

Jeg får en fejl i denne linie:

  if(31==$d && in_array($m, array(4,6,9,11)) $d=30;


gizmo >

Skal jeg forstå det sådan, at hvis jeg henter startdatoen fra en tabel, så kan Mysql klare det uden brug af ekstra programmering ?

Nevermind...

Gizmo's version virker præcis som den skal. Jeg skulle bare lige lave en forbindelse til min Mysql før eksemplet virkede.

Tak for hjælpen begge 2 :o)

Det var dog pokkers. Det er jo snart ikke til at være her for alle de geder, og så må jeg ikke engang have husdyr ;-)

Der manglede en ) sammen med de andre, så der er en klump på 3 )er

Det var en interessant vinkel, du fandt gizmo-gizmo. I betragtning af hvor tit jeg fremhæver det smarte i at bruge DATETIME-felter i stedet for VARCHAR eller lignende for netop at kunne bruge de mange gode funktioner i MySQL, er det lidt underligt, at jeg ikke selv tænkte ad den retning. Måske fordi der ikke ellers var database involveret i spørgsmålet.

Ja, det er faktisk ret genialt hvis jeg selv skal sige det :-) ej. Men det er mig en gåde hvorfor man ikke har samme muligheder i PHP. Jeg mener... datofunktioner er da noget som ALLE bruger.

Måske fordi man faktisk kan gøre de samme ting med passende brug af strtotime() og date() - problemet var så bare, at den server myst1098 kører på tilsyneladende er en Windows-makine, og da PHP internt benytter operativsystemets tidsvariabel, understøtter den ikke datoer før 1970. (Det er fortegnsbitten, der ignoreres eller noget i den stil)

MySQL derimod har sin egen kode, som er uafhængig af operativsystemet.

Giz >

Enig... Det er en lille smule underligt at skulle genopfinde den dybe tallerken til den slags.

Men under alle omstændigheder så løste I jo i fællesskab mit problem og tak for det :o)

Det skal så siges, at min metode virker for alle positive år - dog uden hensyntagen til den julianske kalender, der blev benyttet indtil en gang i 15xx, og under hensyntagen til at årstallet skal kunne være i en talvariabel, som PHP benytter til normale beregninger. Hvis det skulle vise sig at være et problem, kan jeg sagtens lave sammenlægningslinien om til lidt kode, som manuelt regner på strengens indhold i stedet, hvormed begrænsningen vil blive PHPs strengstørrelse, og da manualen siger: " It is no problem for a string to become very large. There is no practical bound to the size of strings imposed by PHP, so there is no reason at all to worry about long strings.", skulle koden være ganske fremtidssikret ;-)

MySQL derimod kan foreløbig "kun" kan håndtere årstal op til 9999. Men mon ikke de når at få den begrænsning fikset, før den når at blive et problem. Desuden kan MySQL kun håndtere årstal ned til 1000.

sandbox >

Det er ok som det er nu. :o)

Fint. Jeg regnede nu heller ikke med at en øvre grænse ved år 2147483647 ville være et problem ;-)

(Desuden vil den endda virke højere end det, da den ved højere værdier benytter float til tallet i stedet for int, og de har normalt 14 betydende cifre.)