php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #79182 IntlDateFormatter::formatObject fails with timezone type 2
Submitted: 2020-01-28 13:00 UTC Modified: 2020-01-28 14:53 UTC
From: _php dot net at jantvrdik dot com Assigned: cmb (profile)
Status: Not a bug Package: Date/time related
PHP Version: 7.4.2 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: _php dot net at jantvrdik dot com
New email:
PHP Version: OS:

 

 [2020-01-28 13:00 UTC] _php dot net at jantvrdik dot com 
Description:
------------
IntlDateFormatter::formatObject() fails when date has timezone type 2. Type 1 and 3 work fine. IntlDateFormatter::format() also works fine.

Test script:
---------------
<?php declare(strict_types = 1);

$typeOne = new DateTimeImmutable('today', new DateTimeZone('+0000'));
$typeTwo = new DateTimeImmutable('today', new DateTimeZone('Z'));
$typeThree = new DateTimeImmutable('today', new DateTimeZone('UTC'));
$locale = 'en';
$format = 'd. MMMM';

foreach ([$typeOne, $typeTwo, $typeThree] as $date) {
    var_dump($date);
    
    $formatter = new IntlDateFormatter($locale, IntlDateFormatter::FULL, IntlDateFormatter::FULL, null, null, $format);
    var_dump($formatter->format($date));
    var_dump(IntlDateFormatter::formatObject($date, $format, $locale));
    echo "\n\n\n";
}

Expected result:
----------------
object(DateTimeImmutable)#1 (3) {
  ["date"]=>
  string(26) "2020-01-28 00:00:00.000000"
  ["timezone_type"]=>
  int(1)
  ["timezone"]=>
  string(6) "+00:00"
}
string(11) "28. January"
string(11) "28. January"



object(DateTimeImmutable)#2 (3) {
  ["date"]=>
  string(26) "2020-01-28 00:00:00.000000"
  ["timezone_type"]=>
  int(2)
  ["timezone"]=>
  string(1) "Z"
}
string(11) "28. January"
string(11) "28. January"



object(DateTimeImmutable)#3 (3) {
  ["date"]=>
  string(26) "2020-01-28 00:00:00.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(3) "UTC"
}
string(11) "28. January"
string(11) "28. January"

Actual result:
--------------
object(DateTimeImmutable)#1 (3) {
  ["date"]=>
  string(26) "2020-01-28 00:00:00.000000"
  ["timezone_type"]=>
  int(1)
  ["timezone"]=>
  string(6) "+00:00"
}
string(11) "28. January"
string(11) "28. January"



object(DateTimeImmutable)#2 (3) {
  ["date"]=>
  string(26) "2020-01-28 00:00:00.000000"
  ["timezone_type"]=>
  int(2)
  ["timezone"]=>
  string(1) "Z"
}
string(11) "28. January"
bool(false)



object(DateTimeImmutable)#3 (3) {
  ["date"]=>
  string(26) "2020-01-28 00:00:00.000000"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(3) "UTC"
}
string(11) "28. January"
string(11) "28. January"

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-01-28 14:53 UTC] cmb@php.net
-Status: Open +Status: Not a bug -Assigned To: +Assigned To: cmb
 [2020-01-28 14:53 UTC] cmb@php.net 
From the IntlDateFormatter::format docs[1]:

| If a DateTime or an IntlCalendar object is passed, its timezone
| is not considered. The object will be formatted using the
| formaterʼs configured timezone

From the IntlDateFormatter::formatObject[2] docs:

| The temporary IntlDateFormatter that will be created will take
| the timezone from the passed in object. The timezone database
| bundled with PHP will not be used – ICU's will be used instead.
| The timezone identifier used in DateTime objects must therefore
| also exist in ICU's database.

`Z` does obviously not exists in ICU's database.

So this is not a bug.

[1] <https://www.php.net/manual/en/intldateformatter.format.php>
[2] <https://www.php.net/manual/en/intldateformatter.formatobject.php>
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Mon May 06 19:01:32 2024 UTC