Magento2: Magento\Framework\Stdlib\DateTime\TimezoneInterface broken for English(United Kingdom) locale

Created on 25 Aug 2017  路  9Comments  路  Source: magento/magento2

Preconditions

  1. Magento CE 2.1.8 bog standard, updated with composer update
  2. Locale set to English (United Kingdom)
  3. Timezone set to Europe/London

Steps to reproduce

  1. Run the following code
        $date1 = $this->datetime->date();
        $output->writeln(print_r($date1,true));
        $date2 = $this->timezone->date($date1);
        $output->writeln(print_r($date2,true));

Expected result

  1. $date1 should be UTC time
  2. $date2 should be an array with time set to local time, in this example UTC+1

Actual result

Set locale to English (United Kingdom)

2017-08-25 15:48:00
DateTime Object
(
    [date] => 2031-02-07 15:48:00.000000
    [timezone_type] => 3
    [timezone] => Europe/London
)

Set locale to English (United States)

2017-08-25 15:46:40
DateTime Object
(
    [date] => 2017-08-25 16:46:40.000000
    [timezone_type] => 3
    [timezone] => Europe/London
)

Clear Description Confirmed Format is valid Ready for Work bug report

Most helpful comment

Seriously? This is still open? And does the Timezone class really return getDateTimeFormat as space-concatenated getDateFormat and getTimeFormat? While expecting the passed pattern that might use comma and space? Or a totally different formatting?

All 9 comments

The module I used to prove concept can be downloaded from

TestTimeZone.zip

It can be invoked by

php bin/magento testtimezone:run

Possibly related to #10580

@gwharton thank you for your bug report.
We've created internal ticket MAGETWO-75374 to track progress on the issue.

Please note this is present on 2.1 and 2.2, and presumably 2.3 aswell.

@ishakhsuvarov This bug has been marked as done, but it is not fixed in 2.2-develop.

To reproduce

Install Magento 2.2-develop
Install and enable test module from TestTimeZone.zip (Details at start of issue)

Here i run it with three different timezones with the en_US locale

developer@noriko:~/dev1.html$ php bin/magento config:set general/locale/code en_US
Value was saved.
developer@noriko:~/dev1.html$ php bin/magento config:set general/locale/timezone America/New_York
Value was saved.
developer@noriko:~/dev1.html$ php bin/magento testtimezone:run
Running TimeZone Test
2018-05-14 14:29:56
DateTime Object
(
    [date] => 2018-05-14 10:29:56.000000
    [timezone_type] => 3
    [timezone] => America/New_York
)

developer@noriko:~/dev1.html$ php bin/magento config:set general/locale/timezone UTC
Value was saved.
developer@noriko:~/dev1.html$ php bin/magento testtimezone:run                      
Running TimeZone Test
2018-05-14 14:30:26
DateTime Object
(
    [date] => 2018-05-14 14:30:26.000000
    [timezone_type] => 3
    [timezone] => UTC
)

developer@noriko:~/dev1.html$ php bin/magento config:set general/locale/timezone Europe/London
Value was saved.
developer@noriko:~/dev1.html$ php bin/magento testtimezone:run                                
Running TimeZone Test
2018-05-14 14:30:35
DateTime Object
(
    [date] => 2018-05-14 15:30:35.000000
    [timezone_type] => 3
    [timezone] => Europe/London
)

developer@noriko:~/dev1.html$ 

Now i run it again with three different timezones with the en_GB locale

developer@noriko:~/dev1.html$ php bin/magento config:set general/locale/code en_GB
Value was saved.
developer@noriko:~/dev1.html$ php bin/magento config:set general/locale/timezone America/New_York
Value was saved.
developer@noriko:~/dev1.html$ php bin/magento testtimezone:run                                   
Running TimeZone Test
2018-05-14 14:32:59
DateTime Object
(
    [date] => 2019-11-08 14:32:00.000000
    [timezone_type] => 3
    [timezone] => America/New_York
)

developer@noriko:~/dev1.html$ php bin/magento config:set general/locale/timezone UTC             
Value was saved.
developer@noriko:~/dev1.html$ php bin/magento testtimezone:run                      
Running TimeZone Test
2018-05-14 14:33:05
DateTime Object
(
    [date] => 2019-11-08 14:33:00.000000
    [timezone_type] => 3
    [timezone] => UTC
)

developer@noriko:~/dev1.html$ php bin/magento config:set general/locale/timezone Europe/London   
Value was saved.
developer@noriko:~/dev1.html$ php bin/magento testtimezone:run                                
Running TimeZone Test
2018-05-14 14:33:11
DateTime Object
(
    [date] => 2019-11-08 14:33:00.000000
    [timezone_type] => 3
    [timezone] => Europe/London
)

developer@noriko:~/dev1.html$ 

@gwharton I guess I moved it to done since linked PR was merged. Moved to To Do again.

I am working on this at #dmcdindia

I think this issue is exposing an underlying problem in the way Magento handles dates and times.

If I set the locale to en_US and call MagentoFrameworkStdlibDateTimeDateTime::date() it returns 2018-05-26 11:45:58

If I set the locale to en_GB and call MagentoFrameworkStdlibDateTimeDateTime::date() it returns 2018-05-26 11:46:05

So, DateTime::date() returns the same format regardless of locale.

However

MagentoFrameworkStdlibDateTimeTimezone::date() is expecting time strings in different formats depending on the locale.

If I look at the IntlDateFormatter object within Timezone::date() and query what date pattern it is expecting then I get the following

If the locale is set to en_US the pattern is expecting to be "M/d/yy, h:mm a"
If the locale is set to en_GB the pattern is expecting to be "dd/MM/y, HH:mm"

(Note that neither of the above patterns match what the time format returned by MagentoFrameworkStdlibDateTimeDateTime::date(), although the en_US pattern returns the correct result when it parses the above time string)

So, should the MagentoFrameworkStdlibDateTimeDateTime::date() function always return the same format regardless of locale, or should it return a locale specific format

or should MagentoFrameworkStdlibDateTimeTimezone::date() function always expect the same input time format regardless of locale, or should it accept locale specific time formats.

Too much for my brain I am afraid, as I would imagine whatever you choose, would have massive impact on everything else.

Seriously? This is still open? And does the Timezone class really return getDateTimeFormat as space-concatenated getDateFormat and getTimeFormat? While expecting the passed pattern that might use comma and space? Or a totally different formatting?

Was this page helpful?
0 / 5 - 0 ratings