GMT till svensk tid

Han tog inte upp Sverige som borde ha ett hedersomnämnande i att krångla med datum.

När vi skulle gå från den julianska till den gregorianska kalendern i början på 1700-talet så gjorde vi inte som de flesta andra länder och bara hoppade över en massa dagar så att vi kom i synk direkt. Vi valde att i stället sköta övergången genom att skippa skottdagar under en 40-årsperiod. Det gjordes ett skottår, men nästa gång det var dags så låg vi i krig, och "glömde" bort det, två (!) gånger i rad.

Uppenbarligen var det ett jobbigt projekt, så då bestämde vi i stället att "äsch, vi går tillbaka till den gamla kalendern igen", men då låg vi ju en dag före (pga det där året då vi kom ihåg att skippa skottdagen). För att fixa det så lade vi till en extra skottdag 1712, så att vi faktiskt "firade" den 30 februari. Så alla som hårdkodat att februari alltid har 28 dagar, eller eventuellt 29 (om året är jämnt delbart med 4, men inte med 100, eller jo: om det också är delbart med 400) har inte tänkt på de stackars 1700-talssvenskarna.

Efterhand märkte vi dock att det ändå vore bra att gå över till den nya kalendern, så då gjorde vi som alla andra och hoppade över en mängd dagar på en gång ändå, och gick från 1753-02-17 direkt till 1753-03-01. Succé.

Summerat så handlar det som han säger om att alltid använda färdiga bibliotek och funktioner. Även då kan det finnas oväntade överraskningar: My First BillG Review [Joel on software], Why is subtracting these two times (in 1927) giving a strange result? [SO], men jag skulle ofta argumentera för att om man ens någon gång känner att man vill implementera egen skottårsräkning, eller definiera hur många dagar det är i en viss månad, så gör man "fel", någonstans, i någon mån (man får göra det, men då måste man veta att det inte är rekommenderat, och varför man frångår detta ändå; det är egentligen bara okunskap som är "fel").

—

Mer relaterat, så hanteras datum vanligen genom att sätta date.timezone i `php.ini` och se till att använda korrekta datatyper när man hanterar datum. MySQL:s `timestamp` konverterar automatiskt alla inkomna datum till UTC från serverns angivna tidszon, och konverterar tillbaka till serverns tidszon när datan hämtas. `datetime` lagrar data i serverns tidszon och utför inte någon konvertering. Så länge inte databasserverns egen tidszon ändras på felaktiga sätt så ska båda sakerna "bara fungera" ™. Se 11.3.1 The DATE, DATETIME, and TIMESTAMP Types i manualen.

Att du får fel tidszon i output låter antingen som att databasservern är inställd på fel tidszon, vilket då antingen betyder att du explicit satt fel tidszon i en conffil (osannolikt) eller att ditt system inte är inställt på rätt tidszon (vore också märkligt, om det nu inte handlar om någon shared hosting-lösning någon annanstans i världen). Alternativt så är det PHP som försöker vara smart och konvertera datumet till sin egen tidszon, men eftersom du inte har satt någon sådan korrekt i `php.ini` så ger den UTC. Du bör få en varning av PHP varje gång du använder datumfunktioner om du inte satt tidszonen explicit, men du kanske har stängt av varningar (vilket många gör när de utvecklar, vilket är kontraproduktivt).

$tm=time();
$rt=mysql_query("insert into guest_book(name,tm,dtl) values('$name','$tm','$dtl')");

`time()` ger Unix-tid, vilket är tidszonsoberoende. Så MySQL-servern kommer internt lagra tiden i den tidszon den föredrar. Kontrollfråga: vilken datatyp är ditt MySQL-fält satt till att vara? `DATETIME`, eller något annat?

(Samvetet bör också notera att din kod är vidöppen för SQL injection — du bör använda `mysqli` eller PDO i stället för `mysql`.)

$dt=date("Y-m-d H:i",$nt['tm']);

Om tidszonen i PHP är rätt inställd så kommer PHP använda den för att omvandla Unix-tid till givet format. Exempel på mitt system:

$ php -r '$time = time(); echo $time."\n".date("U", $time)."\n".date("c", $time)."\n";'
1394002322
1394002322
2014-03-05T07:52:02+01:00

Det visar att `time()` ger Unix-tid, att `date()` formaterat som Unix-tid inte ändrar något på detta, och att `date()` formaterat som "vanlig tid" (ISO 8601) förstår den tidszonsinformation som konfigurerats i PHP.

Testa att göra samma utskrifter i ditt program (de tre jag visar i kodstycket ovan), fast med ditt `$nt['tm']` som input, så att du ser i vilket format MySQL levererar tiden, vilken Unix-tid som PHP anser att det motsvarar samt vilken tidszonstransformation som PHP applicerar. Ifall Unix-tiden i steg 2 är rätt, men PHP skriver fel i steg 3 ("+00:00"): då är det i PHP problemet ligger. Ifall Unix-tiden redan i steg 2 är fel och PHP skriver rätt enligt bästa förmåga, med tidszonsinformation: då är det i databasen, eller kopplingen till databasen, som något är fel.

Liveklocka med Unix-tid för att jämföra.