---

jeg er ved at opbygge en database hvor datoerne går længere tilbage end 1970
som mktime hånderer, hvordan bør jeg løse det ?

Bo

---

spørgsmålet er vel om jeg bør løse det via mysql eller PHP ?

Bo

---

On Sat, 7 Sep 2002 00:05:07 +0200, "Bo Rattenborg"
<bo.rattenborg@[nospam]mail.dk> wrote:

>spørgsmålet er vel om jeg bør løse det via mysql eller PHP ?

MySQL har ingen problemer med ældre datoer end 1970. Det i sig selv er
en god grund til at holde det i MySQL.

Derudover kan MySQL også formattere datoer nogenlunde fleksibelt (fx
give ugedage og deslige).

I det hele taget kan det normalt kun anbefales at flytte logik helt
over i SQL-delen, hvis muligt.

--
- Peter Brodersen

---

Peter Brodersen wrote:
>
> I det hele taget kan det normalt kun anbefales at flytte logik helt
> over i SQL-delen, hvis muligt.

Jeg er helt uenig. Jeg går normalt efter at bruge standard-SQL så vidt
det er muligt, og bruger man det til tider begrænsede standard-SQL, kan
man næsten ikke komme uden om at lave mange formateringer af datoer,
tekststrenge mm. i selve programmeringssproget (f.eks. PHP). Fordelen
ved at holde det hele i standard-SQL er portabilitet - det bliver nemt
at flytte det hele over til en anden SQL-database. En anden fordel er,
at folk, der til dagligt bruger flere forskellige databaser, ikke
behøver at huske to-tre-fire forskellige SQL-datoformateringsfunktioner,
men bare behøver at huske på PHP's. En trejde fordel er, at PHP som
regel har mere avancerede dato- og tekstformateringsfunktioner end
databaseserverne. Mig bekendt er det ikke muligt at få MySQL til at
skrive "Lørdag den 7. september 2002 kl. 01:12", hvilket man kan med PHP.

---

On Sat, 07 Sep 2002 01:13:03 +0200, Jonas Koch Bentzen
<ingen.email@eksempel.dk> wrote:

>> I det hele taget kan det normalt kun anbefales at flytte logik helt
>> over i SQL-delen, hvis muligt.
>Jeg er helt uenig. Jeg går normalt efter at bruge standard-SQL så vidt
>det er muligt, og bruger man det til tider begrænsede standard-SQL, kan
>man næsten ikke komme uden om at lave mange formateringer af datoer,
>tekststrenge mm. i selve programmeringssproget (f.eks. PHP).

Deraf "hvis muligt". Egentligt er vi ikke uenige, for jeg vil bruge
samme argument med at det bliver lettere fx at kopiere en query rundt
blandt fx PHP-scripts og perlscripts, for det samme system. Her taler
vi om et kørende system med flere indgange.

>Fordelen
>ved at holde det hele i standard-SQL er portabilitet - det bliver nemt
>at flytte det hele over til en anden SQL-database.

Jeg kan kun være enig i teorien. Men efterhånden har jeg set mange
tilfælde, hvor folk abstraherer ud i en absurd grad, for "hvis vi en
dag vil omlægge hele vores store driftssystem til at køre ASP på
Win2000 under IIS, eller JSP på en sunkværn, så vil vi kunne gør det
let". Praksis viser, at man - selvfølgelig - ikke bruger tusindevis af
mandetimer på at omlægge et gigantisk system, UDEN at omskrive det,
forbedre det eller lignende. Det giver ingen mening at have så store
projekter, uden at systemet i det mindste kan noget andet end før. Alt
andet er et rent hypotetisk projekt ("Vi brugte 800 mandetimer på at
portere systemet, fordi det teknisk set var muligt").

I praksis forekommer det mig langt mere sandsynligt at man har et
site, der fx er lavet i PHP og har nogle perlscripts kørende i cron,
der tilnærmelsesvis bruger de samme queries, end at man beslutter sig
for fx at portere en MySQL-database over til et dyrt indkøbt
Oracle-system... og så ikke gøre brug af noget Oracle-funktionalitet
overhovedet!

>En anden fordel er,
>at folk, der til dagligt bruger flere forskellige databaser, ikke
>behøver at huske to-tre-fire forskellige SQL-datoformateringsfunktioner,
>men bare behøver at huske på PHP's.

Jeg vil igen hævde, at det er mere normalt med sites med én database
og flere sprog (php, perl, shellscripts, python, ruby...), end sites
med ét sprog og to-tre-fire databaser.

Som sagt tror jeg, vi er enige - men det skal nok omformuleres til at
man må finde fællesnævneren for drift af et site. Som jeg ser det, er
det langt oftere databasen (én database, flere sprog) end sproget
(flere databaser, ét sprog).

>En trejde fordel er, at PHP som
>regel har mere avancerede dato- og tekstformateringsfunktioner end
>databaseserverne. Mig bekendt er det ikke muligt at få MySQL til at
>skrive "Lørdag den 7. september 2002 kl. 01:12", hvilket man kan med PHP.

Deraf "Hvis muligt" ;)

--
- Peter Brodersen

---

Tak for de gode indlæg.

Jeg vælger at holde i det i MySQL, da det betyder at jeg kan slippe for at
formatere datoerne efterfølgende i PHP og MySQLs muligheder fint svarer til
jeg mit behov.

Bo

---

Peter Brodersen wrote:
>
> Som sagt tror jeg, vi er enige - men det skal nok omformuleres til at
> man må finde fællesnævneren for drift af et site. Som jeg ser det, er
> det langt oftere databasen (én database, flere sprog) end sproget
> (flere databaser, ét sprog).

Jeps, jeg tror også, vi er enige, men man kan jo sige, at situationen er
forskellig fra udvikler til udvikler: Nogle skifter database tit, og
nogle skifter sprog tit. Jeg oplever oftere at måtte skifte database
(PostgreSQL/MySQL/Microsoft SQL Server) fra projekt til projekt end at
måtte skifte sprog. Jeg taler dog ikke om at måtte portere et
eksisterende projekt, men derimod om, at kunden i ét projekt kræver, at
jeg bruger MySQL, mens jeg bruger en anden database til et andet
projekt. For at jeg ikke skal gå og huske på fem forskellige
ikke-SQL-standard-måder at gøre tingene på, så er det nemmere for mig at
huske PHP's måder at gøre tingene på - og PHP er oftest fællesnævneren i
de projekter, jeg laver for penge (selv om jeg så eksperimenterer en
masse med andre sprog i fritiden, men altså... Der er ikke de store
penge i sprog som Python og Ruby :)).

Jeg skal da heller ikke være bleg for at indrømme, at min modstand mod
at gøre så meget som muligt i SQL-serveren har en del at gøre med mit
standardrytteri. PHP og de fleste andre scriptsprog har kun én
fortolker, så der er kun én måde at gøre tingene på. Med SQL-servere
derimod er der mange forskellige fortolkere, men for at løse det problem
er der en standard. Problemet er bare, at den standard faktisk ikke
tillader særlig meget, og derfor kommer man meget hurtigt ud i
SQL-databasens hjemmelavede funktioner - og det vil jeg gerne undgå.

---

"Jonas Koch Bentzen" <ingen.email@eksempel.dk> wrote in message
news:albcr2$7ne$1@sunsite.dk...
>. Mig bekendt er det ikke muligt at få MySQL til at
> skrive "Lørdag den 7. september 2002 kl. 01:12", hvilket man kan med PHP.
>

Med en kreativ SELECT sætning og et par tabller skulle det vel nok kunne
klares :)

/Mikkel

---

On Sat, 07 Sep 2002 00:05:07 +0200, Bo Rattenborg wrote:

> spørgsmålet er vel om jeg bør løse det via mysql eller PHP ?

PHP er i sig selv dårlig til at håndtere datoer før 1970, fordi mange af
dens dato-relaterede funktioner blot er wrappere til
standard-library-funktioner, hvis opførsel for præ-1970-datoer ikke er til
at stole på.

Fx. vil næste glibc returnere -1, hvis man forsøger at konvertere en
præ-1970-dato til et unix timestamp; dette er der forskellige argumenter
for (søg på glibc mailing lister). Desværre har Red Hat Linux allerede
inkorporeret denne ændring i Red Hat 7.3, se bl.a.
http://rpms.arvin.dk/glibc/rh73/i686/ for nogle noter ang. dette. AIX og
IRIX opfører sig så vidt jeg mener at have hørt på samme måde.

Noget PHP-kode, som man kan afvikle for at se, hvordan éns
systembiblioteker håndterer negative unixtimestamps:

<?php

$timestamp=mktime(1,1,1,1,1,1969);
print "<p>Timestamp from mktime(1,1,1,1,1,1969): $timestamp, used with";
print '<br> - date("r"): '.date('r',$timestamp); print '<br> -
strftime("%c"): '.strftime('%c',$timestamp);

?>

strftime()-kaldet fejler på alle Linux-installationer, jeg har testet på.
Om mktime() giver -1 eller -31535939 skifter mellem Red Hat Linux 7.2 og
7.3.

PEAR-projektet har sin egen Date-klasse til PHP-kodere:
http://pear.php.net/package-info.php?pacid=57 Denne skulle ikke være
afhængig af unix timestamps og derfor principielt immun overfor problemer
i underliggende systembibliotekers mktime() og lign. implementationer.
Samtidig giver den mulighed for at skabe tids-objekter, hvori timezone
indgår, hvilket er godt: et tidspunkt er ikke meget værd, hvis man ikke er
fuldstændig sikker på, hvilken tidszone, man taler om. Desværre er
klassens dokumentation ikke online, på trods af at dens kode indeholder
PHPDoc tags.

Lidt PEAR Date kodeeksempler:

<?php

require_once 'Date.php';

// Now
$n=new Date();
print '<p>Nu: '.$n->getDate().'</p>';

// In future
$f=new Date();
$f->setDate('2002-12-24 18:30:00');
print '<p>Tid til julemad: '.$f->getDate().'</p>';

// In-past calculations: Sep 08 2002 minus 1111111111 seconds
$p=new Date;
$p->setDate('2002-09-08 00:00:00');
$p->subtractSeconds(1031587908);
print '<p>Fr the epoch: '.$p->getDate().'</p>';

?>

MySQL har tilsyneladende sin egen, platformuafhængige dato-håndtering, der
tilsyneladende håndterer hvad som helst i nyere tid. Til gengæld kunne jeg
mistænke MySQL for at tilbyde nogle underlige tidsfunktioner, der kan give
din SQL portabilitetsproblemer.

PostgreSQL benytter i øvrigt systembibliotekets rutiner til visse
tidstransformationer. Med andre ord kan den gemme alle tidspunkter helt
fint, men i visse tilfælde kan der være problemer, når man skal have
behandlet tidspunkter:
http://fts.postgresql.org/db/mw/index.html?section=-1&word=Redhat+7.3+time+manipulation+bug&action=Search&sdb_d=7&sdb_m=5&sdb_y=2002&sde_d=8&sde_m=7&sde_y=2002&weight=0&format=0&order=1

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Bo Rattenborg wrote:
> jeg er ved at opbygge en database hvor datoerne går længere tilbage end 1970

Jeg har løst et problem magentil ved at lægge datoerne i DATE i MySQL,
og så lave en funktion som parallelforskyder datoerne når de skal
trækkes ud til brug i strftime (som skal have et timestamp)

/* Tids-formattering: da Timestamp kun er gyldigt imellem 1970 og 2037
må vi lave et par parallelforskydninger imellem år hvor ugedag og
forholdet til skudår er ens */

/* input: $Y=år, $B=måned, $d=dag. */

function hcaDato($Y,$B,$d){
if($Y<=1857){
/* 1805+(2037-1985=52) Vi begynder i 1985 og må ikke nå over 2037
hvor timestamp slutter */
$MyY=$Y+180; /* 1805 og 1985 er ens i f.t. ugedag og er begge 1år
efter skudår */
}else if($Y<=1913){ /* 1858+(2037-1982=55) */
$MyY=$Y+124; /* 1858 & 1982 er ens i forhold til ugedag og er begge 2
år efter skudår */
}else if($Y<=1953){ /* 1914+(2037-1998=39) */
$MyY=$Y+84; /* 1914 og 1998 er ugedag-ens og begge 1 år efter skudår */
}else if($Y<1970){
$MyY=$Y+28; /* 1954 og 82 er ugedag-ens og begge 2 år efter skudår */
}else{
$MyY=$Y;
}
$dag=mktime(0,0,0,$B,$d,$MyY);
return strftime("%a %d %B $Y",$dag);
}

Hvis nogen skulle have en lettere og kalender-proof løsning på dette så
er jeg da interesseret .
Tidsregningen i ovenstående begynder i 1805 - gæt selv hvorfor ud fra
funktionsnavnet

> som mktime hånderer, hvordan bør jeg løse det ?

- du lader mktime lave datoerne før 1970 også? - jeg har ikke helt
forstået dig, men brug noget af ovenstående hvis du kan .-)

mvh

Jesper Brunholm

--
Phønix - dansk folk-musik fra unge musikere - http://www.phonixfolk.dk