php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #74562 DateTimeZone->getLocation() returns false
Submitted: 2017-05-09 13:57 UTC Modified: 2018-01-29 23:20 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: schmidt@php.net Assigned: vrana (profile)
Status: Closed Package: Date/time related
PHP Version: 7.1.4 OS: Linux
Private report: No CVE-ID: None
 [2017-05-09 13:57 UTC] schmidt@php.net
Description:
------------
According to the documentation, DateTimeZone::getLocation() returns an array.

However, it returns false when using an unnamed timezone. I would expect it to return an array with dummy values similar to that returned for e.g. Etc/UTC+2.

See also bug 67256 about DateTimeZone::getTransitions().

Test script:
---------------
$dt = new DateTime('2017-01-01 12:00+00:00');
var_dump($dt->getTimezone()->getLocation());


Expected result:
----------------
array(4) {
  ["country_code"]=>
  string(2) "??"
  ["latitude"]=>
  float(0)
  ["longitude"]=>
  float(0)
  ["comments"]=>
  string(0) ""
}

Actual result:
--------------
bool(false)


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-05-14 18:21 UTC] heiglandreas@php.net
-Status: Open +Status: Not a bug
 [2017-05-14 18:21 UTC] heiglandreas@php.net
The docs clearly states that the method will return 'false' in an error case. Not providing a valid timezone IS an error-case.

If you need an array with dummy-values you can always check for a "false" and then create an array with dummy-values.
 [2017-05-15 14:47 UTC] schmidt@php.net
>The docs clearly states that the method will return 'false' in an error case.
Where? I do not see any mention of this on http://php.net/manual/en/datetimezone.getlocation.php
 [2017-05-15 14:53 UTC] schmidt@php.net
In my original report, I wrote "Etc/UTC+2" by mistake. It should read "Etc/GMT+2".
 [2017-05-20 07:48 UTC] schmidt@php.net
Please reopen this bug. heiglandreas@... seems to be referring to something else when he closed it.
 [2017-05-30 11:39 UTC] schmidt@php.net
-Status: Not a bug +Status: Open
 [2017-05-30 11:47 UTC] schmidt@php.net
If this behaviour is intentional, at least the documentation needs to be updated.

However, I think the current behaviour is rather confusing. I understand that DateTimeZone internally has a timezone_type property, but this is not very explicitly described in the documentation. From a UX point of view, I would expect new DateTime('2017-01-01 12:00 Etc/GMT'), new DateTime('2017-01-01 12:00Z'), new DateTime('2017-01-01 12:00 UTC') and new DateTime('2017-01-01 12:00+00:00') to have the same location.
 [2018-01-29 23:20 UTC] vrana@php.net
Automatic comment from SVN on behalf of vrana
Revision: http://svn.php.net/viewvc/?view=revision&revision=344087
Log: Document returning false (bug #74562)
 [2018-01-29 23:20 UTC] vrana@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: vrana
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 12:01:31 2024 UTC