Possible bug in DateTimeZone class

Hello, I have problem with date timezone. Running Windows 10, PHP 7.1.10.

When I use this code:

date_default_timezone_set('UTC');
var_dump(new \DateTime("2018-09-01", new \DateTimeZone(date_default_timezone_get())));
var_dump(new \DateTime("2018-09-01"));
date_default_timezone_set('CET');
var_dump(new \DateTime("2018-09-01", new \DateTimeZone(date_default_timezone_get())));
var_dump(new \DateTime("2018-09-01"));

The output is:

object(DateTime)#692 (3) {
  ["date"]=>
  string(26) "2018-09-01 00:00:00.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(3) "UTC"
}
object(DateTime)#692 (3) {
  ["date"]=>
  string(26) "2018-09-01 00:00:00.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(3) "UTC"
}
object(DateTime)#692 (3) {
  ["date"]=>
  string(26) "2018-09-01 00:00:00.000000"
  ["timezone_type"]=>
  int(2)
  ["timezone"]=>
  string(3) "CET"
}
object(DateTime)#692 (3) {
  ["date"]=>
  string(26) "2018-09-01 00:00:00.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(3) "CET"
}

So, if I use UTC as timezone, result is same for creating DateTime with or without specifying second parameter (timezone). But when I use CET as timezone, results differs in timezone_type.

My question is, it’s a PHP bug, or when I must use second parameter (not null value), what is right value to get same result as without second parameter?

How is that a bug? You are specifying what you want. Take the following:

I specify second parameter, this is true.

I use nesbot/carbon package with Laravel. Carbon instance can be created by multiple ways.
Code:

date_default_timezone_set('CET');
var_dump(new Carbon("2018-09-01 12:00:00"));
var_dump(Carbon::parse("2018-09-01 12:00:00"));
var_dump(Carbon::createFromFormat("Y-m-d H:i:s", "2018-09-01 12:00:00"));

Result:

object(Illuminate\Support\Carbon)#552 (3) {
  ["date"]=>
  string(26) "2018-09-01 12:00:00.000000"
  ["timezone_type"]=>
  int(2)
  ["timezone"]=>
  string(3) "CET"
}
object(Illuminate\Support\Carbon)#552 (3) {
  ["date"]=>
  string(26) "2018-09-01 12:00:00.000000"
  ["timezone_type"]=>
  int(2)
  ["timezone"]=>
  string(3) "CET"
}
object(Illuminate\Support\Carbon)#557 (3) {
  ["date"]=>
  string(26) "2018-09-01 12:00:00.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(3) "CET"
}

But some ways of creating Carbon instance don’t use second parameter and some ways use second parameter (new \DateTimeZone(date_default_timezone_get())). And it cause that it creates date instances with different timezone_type and it’s problem.

PHP documentation say that if second parameter (timezone) is omitted, the current timezone will be used.
I thought (maybe as Carbon package programmers) that I can get current timezone with this code new \DateTimeZone(date_default_timezone_get()). And I thought if I create DateTime instance with this code as second parameter or with empty second parameter, I get DateTime instance with same timezone.

So thats why I ask if it’s a bug or if I use wrong second parameter.

How can I get current timezone (mentioned in PHP documentation) that when I use it, it returns DateTime instance with same timezone_type as when I use empty second parameter?

If I understand what you are wanting, use the timezone they support, not the abbreviation for it.

date_default_timezone_set('Europe/Berlin');
var_dump(new \DateTime('20018-09-01', new DateTimeZone(date_default_timezone_get())));

Thank you for your time. I will use specific timezone.

But still it make no sense to me, that it return different timezone_type for CET timezone. I wonder how PHP internally creating DateTimeZone instance for CET for DateTime instance (with empty second parameter), which is different if I manually creating DateTimeZone instance for CET. But now I noticed warning about use it in PHP documentation.

Timezones can be one of three different types in DateTime objects:

  • Type 1; A UTC offset, such as in new DateTime("17 July 2013 -0300");
  • Type 2; A timezone abbreviation, such as in new DateTime("17 July 2013 GMT");
  • Type 3: A timezone identifier, such as in new DateTime( "17 July 2013", new DateTimeZone("Europe/London"));

I read that. But I don’t know why if I create DateTimeZone instance with CET timezone, it is timezone abbreviation. But if PHP create DateTimeZone instance itself (when creating DateTime instance) with CET timezone, it is timezone identifier. Maybe there is a reason for it, but I can’t see it.

One again, thank you for your time.

Sponsor our Newsletter | Privacy Policy | Terms of Service