Tutorials >
MySQL >
Datum en tijd in MySQL [deel 2: Functies]
|
|
 Gepost op: 29 september 2006 - 19:04 |
|
|
|
PHP gevorderde
 |
Goede tut  , Ik moet dus ook binnekort maar is overschakelen, ik zal dit dus zeker nog wel is doorlezen |
|
|
|
|
| Gepost op: 09 maart 2007 - 19:22 |
|
|
|
PHP ver gevorderde
|
Ik heb in mijn db een datetime staan als YYYY-mm-dd H:i:s.
Hoe kan ik deze als een timestamp (dus het aantal seconden vanaf 1-1-1970) uit de db halen?
Edit:
Oke, bedankt.
Ik pas hem trouwens toe op een DELETE query.
Ik laat nog weten (over 1 à 2 dagen kan dat pas) of hij daar ook werkt.
Werkt! |
|
|
|
|
| Gepost op: 09 maart 2007 - 19:40 |
|
|
|
Beheerder
|
Probeer de functie UNIX_TIMESTAMP(veldnaam) eens in je query.
Heb hem getest en is inderdaad de functie |
|
|
|
|
| Gepost op: 29 april 2007 - 16:15 |
|
|
|
PHP ver gevorderde
|
Citaat: SELECT ADDDATE('2006-01-01', INTERVAL 1 year); geeft dus 2006-02-01
Moet dit niet 2007-02-01 zijn? Anders snap ik niet waar die 'INTERVAL 1 year' voor staat.. |
|
|
|
|
| Gepost op: 30 april 2007 - 22:32 |
|
|
|
Beheerder
|
| idd Dark_Paul heb het alsnog even aangepast. |
|
|
|
|
| Gepost op: 03 maart 2009 - 16:10 |
|
|
|
Crew algemeen
|
Citaat: Wat was de dag op .....
Doe ik persoonlijk via date_format, zo krijg je rechtstreeks de volledige naam (of afgekort als je dat wenst) en kan je evt andere datum gegevens ook al in de string gebruiken (zoals bvb een jaartal, een maand of een dag)
DATE_FORMAT(time, '%M %D %Y')
DATE_FORMAT(time, '%M %D %Y')
zal geven: (op 3 maart 2009)
|
|
|
|
|
| Gepost op: 21 mei 2014 - 20:33 |
|
|
|
Moderator
|
Iets wat ik in beide tutorials mis is een kanttekening over tijdszones. Ook wordt er gedaan alsof unix timestamps (altijd) slecht zijn en (DATE)TIME (altijd) goed. Dit is niet zo.
Toegegeven, timestamps hebben limitaties, maar DATE(TIME) ook!
Timestamps hebben een redelijk beperkt waardenbereik (en ik ben benieuwd wat er in 2038 gaat gebeuren, dit wordt waarschijnlijk een groter issue dan het "millenium probleem").
(DATE)TIME(s) daarintegen hebben geen enkel benul van de tijdszone waarop deze van toepassing zijn en de functies die hier op werken voeren hier (dus) ook geen aanpassingen op uit.
Citaat: The current time zone setting does not affect values displayed by functions such as UTC_TIMESTAMP() or values in DATE, TIME, or DATETIME columns. Nor are values in those data types stored in UTC; the time zone applies for them only when converting from TIMESTAMP values. If you want locale-specific arithmetic for DATE, TIME, or DATETIME values, convert them to UTC, perform the arithmetic, and then convert back.
Oftewel, tenzij je hiervoor speciale voorzieningen voor treft of dingen expliciet instelt, slaat MySQL (DATE)TIME-waarden op afhankelijk van de (vooringestelde) tijdszone. Als deze (vooringestelde) tijdszone verandert worden je DATE(TIME) waarden niet aangepast, simpelweg omdat deze zich niet bewust zijn van een tijdszone...
Timestamps hierintegen hebben ALTIJD dezelfde tijdszone als uitgangspunt (UTC) en bepaalde MySQL-funties (maar ook PHP-functies!) voeren automatisch vertalingen uit vanuit UTC naar de actuele tijdszone. Door dit vaste uitgangspunt wordt een en ander ineens compleet ondubbelzinnig. Net zoals tekst zonder voorgeschreven character encoding onzinnig is (en eigenlijk niet bestaat) is de definitie van een tijdstip onzinnig zonder vermelding van de tijdszone.
Er moet (wat mij betreft) altijd een bewustwording van een tijdszone zijn, hetzij in je applicatie, hetzij in je database. Er is trouwens niets wat je ervan weerhoudt om DATE(TIME) waarden op te slaan in de UTC-tijdszone, maar je zult dan dus zelf je tijdszone vertalingen moeten uitvoeren. In dat geval zijn timestamps een veel beter alternatief.
Vragen als "hoe laat is het in tijdszone X op (een) tijdstip Y (in de eigen tijdszone)" zijn met timestamps kinderspel.
Stel dat een of ander online evenement begint op 4 april 2014 om 7 uur 's-ochtends Pacifische Tijd. Hoe laat begint dat dan hier (CEST)? Voor timestamps is dit een koud kunstje:
<?php
date_default_timezone_set('America/Los_Angeles');
$time = mktime(7, 0, 0, 4, 4, 2014);
echo date('Y-m-d H:i:s', $time).' PDT equals ';
date_default_timezone_set('Europe/Amsterdam');
echo date('Y-m-d H:i:s', $time).' CEST';
?>
<?php date_default_timezone_set('America/Los_Angeles'); $time = mktime(7, 0, 0, 4, 4, 2014); echo date('Y-m-d H:i:s', $time).' PDT equals '; date_default_timezone_set('Europe/Amsterdam'); echo date('Y-m-d H:i:s', $time).' CEST'; ?>
levert
2014-04-04 07:00:00 PDT equals 2014-04-04 16:00:00 CEST
2014-04-04 07:00:00 PDT equals 2014-04-04 16:00:00 CEST
Hierbij moet je wel goed begrijpen wat er gebeurt. mktime() is een timezone-aware functie en zal de gegenereerde timestamp, ondanks het feit dat deze in de Pacifische tijdszone is opgesteld terugvertalen naar UTC. Vervolgens schakel je naar CEST (Europe/Amsterdam). Je drukt dan de date() van de timestamp af. Maar deze functie is ook weer timezone-aware en zal dus de timestamp (=UTC) terugvertalen naar de actuele tijdszone.
Als de tijdszone je niet uitmaakt werken DATE(TIME) kolommen prima, of zelfs elke kolom die sorteerbaar is die voor tijden en datums zinnig is (al kun je dan minder goed datum en tijdfuncties gebruiken). Maar er is dus ZEKER iets voor te zeggen (ook in het kader van internationalisatie) om timestamps te gebruiken...
Je moet je wel terdege bewust zijn van de vertalingen die op de achtergrond worden uitgevoerd op unix timestamps (bij gebruikmaking van timezone-aware functies, bijvoorbeeld) en dat wat je geretoureerd krijgt dus sterk af kan hangen van de ingestelde tijdszone. |
|
|
| Enkel aanvullende informatie is welkom. Geen prijzende of afkeurende reacties. |
|
|
|
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
