Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Magento\Framework\Stdlib\DateTime\TimezoneInterface broken for English(United Kingdom) locale #10663

Closed
gwharton opened this issue Aug 25, 2017 · 9 comments
Labels
bug report Issue: Clear Description Gate 2 Passed. Manual verification of the issue description passed Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development

Comments

@gwharton
Copy link
Contributor

gwharton commented Aug 25, 2017

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
)

@gwharton
Copy link
Contributor Author

gwharton commented Aug 25, 2017

The module I used to prove concept can be downloaded from

TestTimeZone.zip

It can be invoked by

php bin/magento testtimezone:run

@gwharton
Copy link
Contributor Author

Possibly related to #10580

@magento-engcom-team magento-engcom-team added G1 Passed bug report Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed Issue: Clear Description Gate 2 Passed. Manual verification of the issue description passed and removed G1 Passed labels Sep 5, 2017
@okorshenko okorshenko added the Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed label Sep 14, 2017
@magento-engcom-team
Copy link
Contributor

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

@magento-engcom-team magento-engcom-team added the Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development label Sep 19, 2017
@gwharton
Copy link
Contributor Author

gwharton commented Nov 8, 2017

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

@gwharton
Copy link
Contributor Author

@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$ 

@ishakhsuvarov
Copy link
Contributor

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

@yogeshsuhagiya yogeshsuhagiya self-assigned this May 19, 2018
@yogeshsuhagiya
Copy link
Member

I am working on this at #dmcdindia

@gwharton
Copy link
Contributor Author

gwharton commented May 26, 2018

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 \Magento\Framework\Stdlib\DateTime\DateTime::date() it returns 2018-05-26 11:45:58

If I set the locale to en_GB and call \Magento\Framework\Stdlib\DateTime\DateTime::date() it returns 2018-05-26 11:46:05

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

However

\Magento\Framework\Stdlib\DateTime\Timezone::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 \Magento\Framework\Stdlib\DateTime\DateTime::date(), although the en_US pattern returns the correct result when it parses the above time string)

So, should the \Magento\Framework\Stdlib\DateTime\DateTime::date() function always return the same format regardless of locale, or should it return a locale specific format

or should \Magento\Framework\Stdlib\DateTime\Timezone::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.

@deb00t
Copy link

deb00t commented Nov 21, 2018

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?

@gwharton gwharton closed this as completed Jul 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug report Issue: Clear Description Gate 2 Passed. Manual verification of the issue description passed Issue: Confirmed Gate 3 Passed. Manual verification of the issue completed. Issue is confirmed Issue: Format is valid Gate 1 Passed. Automatic verification of issue format passed Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development
Projects
None yet
Development

No branches or pull requests

8 participants