Event Relative Time - php

Question

So here's the scenario:
My application has a transaction section in it. It logs actions and stores the time as a UNIX timestamp (UTC).
So yesterday I got paid £100.00 and this was logged into the database with a unix timestamp of 1477762205 which equates to Sat, 29 Oct 2016 17:30:05 UTC/GMT.
(This is 19:30 local time for me)
My application (written in PHP) outputs using a datetime object and passing in the output timezone (Europe/London).
Yesterday it outputted correctly local time as 19:30 and due to the clock time change this morning at 2am it now reads 18:30.
This is technically correct but if I remember back relative to the event when logging the transaction in the first place this will now seem incorrect as I remember it being 19:30 local time.
My question is what is the best way to output the time from UTC, relative to the event? Do I need to store the timezone with the UTC log to determine the timezone at the point the log took place?
Code:
When storing the log:
(This is part of a logger class I'm creating)
if($dateTime == null) {
$dateTime = time();
}
$query = "INSERT INTO `".$this->databaseName."`.`log`(`datetime`,`action`) VALUES(?, ?);";
if(!$stmt = $this->database->prepare($query)) {
return $this->database->error;
}
$stmt->bind_param('ss',$dateTime,$action);
$stmt->execute();
When outputting this:
$dateTime = new DateTime(null, new DateTimeZone('UTC'));
$dateTime->setTimestamp($log->timeStamp);
$dateTime->setTimezone(new DateTimeZone('Europe/London'));
echo $dateTime->format('d/m/Y H:i');
Techincally correct output: 29/10/2016 18:30
But I wish for it to display being DST aware relative to the actual timestamp, not the DST relative to now.
So I wish for it to output: 29/10/2016 19:30

Answer 1

First of all, let's summarise the expected local values for 1477762205 Unix timestamp:
UTC: 17:30:05 (UTC, +0000)
London: 18:30:05 (BST, +0100 aka 3600, DST=1)
Madrid: 19:30:05 (CEST, +0200 aka 7200, DST=1)
Stuff seems to work as expected as long as you use city-based time zone identifiers:
foreach (['UTC', 'Europe/London', 'Europe/Madrid'] as $time_zone_id) {
$dt = new DateTime('#1477762205');
$tz = new DateTimeZone($time_zone_id);
$dt->setTimezone($tz);
echo $time_zone_id . ': ' . $dt->format('H:i:s [e=T, O]') . PHP_EOL;
}
UTC: 17:30:05 [UTC=UTC, +0000]
Europe/London: 18:30:05 [Europe/London=BST, +0100]
Europe/Madrid: 19:30:05 [Europe/Madrid=CEST, +0200]
As soon as we use named zones acronyms, strange things happen:
foreach (['UTC', 'BST', 'GMT', 'CEST', 'CET'] as $time_zone_id) {
$dt = new DateTime('#1477762205');
$tz = new DateTimeZone($time_zone_id);
$dt->setTimezone($tz);
echo $time_zone_id . ': ' . $dt->format('H:i:s [e=T, O]') . PHP_EOL;
}
UTC: 17:30:05 [UTC=UTC, +0000]
BST: 17:30:05 [BST=BST, +0000]
GMT: 17:30:05 [GMT=GMT, +0000]
CEST: 18:30:05 [CEST=CEST, +0100]
CET: 18:30:05 [CET=CET, +0100]
There's probably some relation with the information (or lack of it) about time zone transitions available in the underlying database:
$dt = new DateTime('#1477762205');
foreach (['UTC', 'BST', 'Europe/London', 'CEST', 'Europe/Madrid'] as $time_zone_id) {
$tz = new DateTimeZone($time_zone_id);
$dt->setTimezone($tz);
echo $time_zone_id . PHP_EOL;
echo '- Time zone offset: ' . $tz->getOffset($dt) . ' seconds' . PHP_EOL;
$transitions = $tz->getTransitions(mktime(0, 0, 0, 1, 1, 2016), mktime(0, 0, 0, 12, 31, 2016));
if ($transitions===false) {
echo '- Error fetching transitions' . PHP_EOL;
} else {
echo '- ' . count($transitions) . ' transitions found' . PHP_EOL;
}
}
UTC
- Time zone offset: 0 seconds
- 1 transitions found
BST
- Time zone offset: 0 seconds
- Error fetching transitions
Europe/London
- Time zone offset: 3600 seconds
- 3 transitions found
CEST
- Time zone offset: 3600 seconds
- Error fetching transitions
Europe/Madrid
- Time zone offset: 7200 seconds
- 3 transitions found
It's really hard to say how much of this is a plain bug and how much is counter-intuitive but documented; the PHP bug database is crowded with not a bug entries which are indeed a misunderstanding but I've personally found weird but actual bugs in date calculations involving DST boundaries.