Hhvm: DateInterval around DST incompatible with PHP

[GDmac]

HHVM Version

hhvm-3.12.0 - 3.13.2
Test at: https://3v4l.org/LCvJD

Standalone code, or other way to reproduce the problem

DST changes on last sunday of october 03:00 => 02:00

// interval one day. Counts days
$dateTime = new DateTime('2016-10-29 10:00:00');
$dateTime->add(new DateInterval('P1D'));
print_r($dateTime); // 2016-10-30 10:00

// interval 24 hours. PHP counts hours, HHVM counts days ?
$dateTime = new DateTime('2016-10-29 10:00:00');
$dateTime->add(new DateInterval('PT24H'));
print_r($dateTime); // 2016-10-30 09:00

Expected result

// Output for PHP 5.6.0 - 5.6.29, 7.0.0 - 7.1.0
DateTime Object
(
    [date] => 2016-10-30 10:00:00.000000
    [timezone_type] => 3
    [timezone] => Europe/Amsterdam
)
DateTime Object
(
    [date] => 2016-10-30 09:00:00.000000
    [timezone_type] => 3
    [timezone] => Europe/Amsterdam
)}

Actual result

// Output for hhvm-3.12.0 - 3.13.2
DateTime Object
(
    [date] => 2016-10-30 10:00:00.000000
    [timezone_type] => 3
    [timezone] => Europe/Amsterdam
)
DateTime Object
(
    [date] => 2016-10-30 10:00:00.000000
    [timezone_type] => 3
    [timezone] => Europe/Amsterdam
)

issue found via http://www.mendoweb.be/blog/php-dateinterval-dst-change/

[photodude]

This seems server/TimeZone specific
I tested on Travis CI for php 5.6, 7.0, 7.1, nightly (7.2) and HHVM 3.15.3, 3.16.0-dev (with and without hhvm's PHP7 mode)

my tests https://travis-ci.org/photodude/HHVM_code_snip_tests/builds/183144904

I got the following on all tests (TimeZone UTC)

// Output for php 5.6-7.2-dev and HHVM 3.15.3-3.16.0-dev
object(DateTime)#1 (3) {
  ["date"]=>
  string(26) "2016-10-30 10:00:00.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(3) "UTC"
}
object(DateTime)#2 (3) {
  ["date"]=>
  string(26) "2016-10-30 10:00:00.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(3) "UTC"
}

You can see the same result if you force UTC on your code snip
https://3v4l.org/sEnpg

[photodude]

Here is a corrected code snip that shows the behavior issues listed above that are TimeZone specific.

<?php
$dateTime = new DateTime('2016-10-29 10:00:00', new DateTimeZone('Europe/Amsterdam'));
$dateTime->add(new DateInterval('P1D'));
var_dump($dateTime); // expected 2016-10-30 10:00

$dateTime = new DateTime('2016-10-29 10:00:00', new DateTimeZone('Europe/Amsterdam'));
$dateTime->add(new DateInterval('PT24H'));
var_dump($dateTime); // expected 2016-10-30 09:00

HHVM is calculating the same way with UTC as with 'Europe/Amsterdam'

Under UTC TimeZone we get "2016-10-30 10:00:00.000000" for both DateTime calculated objects (same as with PHP) https://3v4l.org/sEnpg and https://travis-ci.org/photodude/HHVM_code_snip_tests/builds/183144904

but under 'Europe/Amsterdam' TimeZone in HHVM we get the same values as UTC but not the same values as PHP.
https://travis-ci.org/photodude/HHVM_code_snip_tests/builds/183148633
and https://3v4l.org/LCvJD

[Orvid]

PHP hard-codes the time table into the library, and a few distros patch PHP specifically to have it use the system timezone info. HHVM's copy of timelib was also patched to use the system timezone database, however it appears that when I applied the update to timelib from upstream (https://github.com/hhvm/hhvm-third-party/commit/1f0c11effde2a4a3ae568ff2941531e4170a527c) it appears I didn't re-apply the patch in https://github.com/hhvm/hhvm-third-party/commit/2ad7a554f5bd9446a966de24c9abfc77bc43a62d, so we are using the timelib db from 2016. 6f, rather than the system timelib db. Once I figure out the issue with our sync to github I'll re-apply that patch to our version and do some testing.

The time zones that are different are likely due to the differences in which version of the timezone DB is used.