php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #66102 DateTimeZone::listIdentifiers does not return linked timezone
Submitted: 2013-11-15 12:23 UTC Modified: 2014-08-11 10:25 UTC
Votes:16
Avg. Score:4.1 ± 1.1
Reproduced:15 of 16 (93.8%)
Same Version:9 (60.0%)
Same OS:12 (80.0%)
From: a dot servedio at technotraffic dot com Assigned:
Status: Not a bug Package: Date/time related
PHP Version: Irrelevant OS: Linux, might be any
Private report: No CVE-ID: None
 [2013-11-15 12:23 UTC] a dot servedio at technotraffic dot com
Description:
------------
America/Montreal timezone was changed from a distinct timezone (entry in zone.tab) to a linked timezone (linked to America/Toronto).

This change comes from a iana update (2013e) introduced in september 2013. But other previous "linked" timezone don't show up in listIdentifiers as well.

While not being a distinct timezone, these are still valid (See comment from TZ Maintainer at iana: https://github.com/eggert/tz/commit/45dcf69b45087cff50282d4da64b86a7d705ddf3#commitcomment-4602830)

(issue occurs in both 5.3.10 and 5.5.5 as far as I know)

Test script:
---------------
// all valid timezones, except last 2 are timezone "links"
$timezones = array('America/Toronto', 'America/Montreal', 'Asia/Istanbul');

// they are all valid here. No Exceptions thrown
foreach($timezones as $tz) {
  new \DateTimeZone($tz);
  echo "Timezone object valid with $tz \n";
}

// checking against identifiers list, will not find it for the last 2 timezones
$tz_list = \DateTimeZone::listIdentifiers();
foreach($timezones as $tz) {
  echo "Timezone $tz ";
  echo in_array($tz, $tz_list) ? "in list\n" : "NOT in list\n";
}

Expected result:
----------------
Timezone object valid with America/Toronto 
Timezone object valid with America/Montreal 
Timezone object valid with Asia/Istanbul 
Timezone America/Toronto in list
Timezone America/Montreal in list
Timezone Asia/Istanbul in list

Actual result:
--------------
Timezone object valid with America/Toronto 
Timezone object valid with America/Montreal 
Timezone object valid with Asia/Istanbul 
Timezone America/Toronto in list
Timezone America/Montreal NOT in list
Timezone Asia/Istanbul NOT in list

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-08-09 03:57 UTC] mal dot graty at idioplatform dot com
If I understand correctly, this is expected behaviour.

America/Montreal is, in effect, deprecated. It will still work, for anything already using it, but going forward America/Toronto should be chosen instead.

This decision was taken by the IANA, and isn't related to PHP.

There have been discussions here (https://github.com/eggert/tz/commit/242980fc79ef5fb676383f91505f9cbce6ff74cb#commitcomment-5248365) and here (https://github.com/eggert/tz/issues/4) that explain the reasoning for doing so.

tl;dr: Linked timezones function, but do not appear in DateTimeZone::listIdentifiers by design, since they are only linked for backward compatibility, and should not be used going forward where possible.
 [2014-08-09 09:25 UTC] a dot servedio at technotraffic dot com
Hi, thank you for taking the time to answer.

The iana maintainer is the same person in both my bug description link and the link you provide.

Now reading both comments, it seems like the reasoning for the "backward" list isn't only for timezones that may be deprecated, but also for timezones that provides the same end result as another one and are being provided as "links" instead of distinctive entries.

From the url you provide, he mentions "America/Montreal is redundant", not "deprecated".

He also says "The TZ setting 'America/Montreal' should work as it did before, for all time stamps after 1970." in his answer on my link.

Which is probably why <?php new \DateTimeZone("America/Montreal") ?> works.

Which is probably also why the recent tzdata package in Linux will still create a fully usable /usr/share/zoneinfo/America/Montreal entry as of today, and that /etc/timezone can hold 'America/Montreal' no problem.
 [2014-08-09 11:30 UTC] mal dot graty at idioplatform dot com
Yup, I agree with all of that. :)

However it's these two comments specifically that makes me think that it's not expected to be returned from the listIdentifiers function: https://github.com/eggert/tz/commit/242980fc79ef5fb676383f91505f9cbce6ff74cb#commitcomment-5248692 and https://github.com/eggert/tz/issues/4#issuecomment-27102005

I interpret it as: for anyone already using America/Montreal they should see no change (i.e. can still be used for time calculations) but it should be omitted from the list because America/Toronto should be used in preference going forward.

In my view DateTimeZone::listIdentifiers is correct in listing only distinct identifiers, keeping the list to a bare minimum to choose from (the full list is double the length). This also ensures that everything in the list has country and lat/lon info, something backward links do not have.

For TZ validation, a try catch around the constructor seems like the best approach. However if you do need a complete list for some purpose, it can be derived from DateTimeZone::listAbbreviations as shown in the script below.

Test script:
---------------
// compile
$abbrs = \DateTimeZone::listAbbreviations();
$usable_tzs = array_unique(array_filter(
    array_merge(array_map('strtoupper', array_keys($abbrs)), array_reduce(
        $abbrs,
        function ($tzs, $abbr) {
            return array_merge($tzs, array_map(
                function ($tz) {
                    return $tz['timezone_id'];
                },
                $abbr
            ));
        },
        array()
    )),
    function ($tz) {
        return strlen($tz) > 1;
    }
));

// validate
foreach ($usable_tzs as $tz) {
    try {
        new DateTimeZone($tz);
    } catch (Exception $e) {
        echo $tz . ' is NOT a valid timezone' . PHP_EOL;
    }
}

// test
var_dump(in_array('America/Montreal', $usable_tzs));
var_dump(count(DateTimeZone::listIdentifiers()));
var_dump(count($usable_tzs));



Result:
----------------
bool(true)
int(417)
int(834)
 [2014-08-09 12:33 UTC] a dot servedio at technotraffic dot com
I see your point..

If you are building an interface that list timezones, 417 distinctive TZ is already long enough. But if you want to validate a user supplied value, or a database value, that list should not be used for validation.

Basically:

\DateTimeZone::listIdentifiers(); /* distinctive timezones */
\DateTimeZone::listAbbreviations(); /* all timezones */
new \DateTimeZone($tz); /* all timezones */
ini_set('date.timezone', 'America/Montreal'); /* all timezones */
/etc/timezone content on Linux /* all timezones */

This inconsistency made me certain that this was a bug but it's more of a way to help those building a selection menu.

I believe listIdentifiers() should still return all timezones by default and act like the other TZ functions in php and other systems around. To simplify tz select menu builders, perhaps the function could get upgraded with a parameter like \DateTimeZone::listIdentifiers($distinctive_only = false).

But I guess to not mess up those already using this function that doesn't want linked TZ or that doesn't know about them, the parameter could be more like $distinctive_only = true by default.

Either way, with or without any modification to listIdentifiers function, this info about linked tz and distinctive tz should go into the manual for that function. It would help developers that uses this function for other cases beside building a fully loaded tz selection list, which involves linked timezones that are used in other systems and are in fact still valid.
 [2014-08-11 10:25 UTC] derick@php.net
-Status: Open +Status: Not a bug
 [2014-08-11 10:25 UTC] derick@php.net
Just to comment in the previous comment, which gets things quite a bit wrong:

| \DateTimeZone::listIdentifiers(); /* distinctive timezones */

It actually by default returns all timezone IDs that are not being "deprecated".

| \DateTimeZone::listAbbreviations(); /* all timezones */

Abbreviations are *not* timezones. Please do not think that abbreviations are unique, as they are not.

| This inconsistency made me certain that this was a bug but it's more of a way
| to help those building a selection menu.

| I believe listIdentifiers() should still return all timezones by default and
| act like the other TZ functions in php and other systems around. To simplify
| tz select menu builders, perhaps the function could get upgraded with a
| parameter like \DateTimeZone::listIdentifiers($distinctive_only = false).

Actually, the choice was made the other way around just because the reason you mention: We don't want 'duplicates' in lists.

And it is already quite possible to really list *all* identifiers:

$l2 = DateTimeZone::listIdentifiers( DateTimeZone::ALL_WITH_BC );

You can compare which identifiers are "deprecated" through:

<?php
$l1 = DateTimeZone::listIdentifiers();
$l2 = DateTimeZone::listIdentifiers( DateTimeZone::ALL_WITH_BC );
$l = array_diff($l2, $l1);
var_dump($l);
 [2014-08-11 14:53 UTC] a dot servedio at technotraffic dot com
Hi Derick, and thank you for your answers.

I understand your points.

It's great that there already is a parameter to include linked timezone in the "backward" list.

America/Montreal and America/Toronto are both valid timezone Identifiers as of today and from Iana's perspective. America/Montreal was changed to be a link to America/Toronto since they end up doing the same thing to dates. It has not become deprecated, and it will not be removed from the timezone list in a foreseeable future

<?php

// instantiate DateTimeZone
new \DateTimeZone("America/Toronto"); /* Works. No exception thrown */
new \DateTimeZone("America/Montreal"); /* Works. No exception thrown */

// get identifiers and identifiers + linked timezone (since 5.3.0)
$tz_ids = DateTimeZone::listIdentifiers();
$tz_ids_all = DateTimeZone::listIdentifiers(DateTimeZone::ALL_WITH_BC);

// test
var_dump(in_array('America/Toronto', $tz_ids))); /* true */
var_dump(in_array('America/Montreal', $tz_ids)); /* false */
var_dump(in_array('America/Montreal', $tz_ids_all)); /* true */

?>

So yes, it's not a bug. DateTimeZone::listIdentifiers CAN return linked timezones.

Would that info be a valid candidate for a comment to that function in the manual? It might help those that got confused like me and where using for many years a timezone that became a linked timezone.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Tue Sep 17 13:01:36 2019 UTC