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