Magento 2 Timezone Issue

[shahankitb997]

Preconditions

1. Go to Admin -> Stores -> Configuration -> General -> Locale Options.
   Timezone set to "Singapore Standard Time (Asia/Singapore)"

On magento2\app\bootstrap.php at end of file there is static line written date_default_timezone_set('UTC');

If i need Magento Date

$magentoDateObject = $objectManager->create('Magento\Framework\Stdlib\DateTime\DateTime');
$magentoDate = $magentoDateObject->gmtDate();

I have to go to the file & change

Steps to reproduce

1. Line should be removed from magento2\app\bootstrap.php date_default_timezone_set('UTC');

Expected result

1. So will get Acutal Date

Actual result

1. [Screenshot, logs]

[veloraven]

@shahankitb997 thank you for your report.
Please specify Magento version you are running

[shahankitb997]

Magento 2 CE Version 2.1.2

[Ctucker9233]

@veloraven This bug also affects newsletter queue. See issue #5943.

[shahankitb997]

@Ctucker9233 You are correct. I'm not able to send newsletter as per set on Admin Locale.
http://magento.stackexchange.com/questions/147752/magento-2-newsletter-queue-take-different-queue-start-time

Don't know why they have put Static code for setting TimeZone? It's pointless to provide Admin Settings for Locale Timezone. If you are going to override it.

There should be only one way to set Timezone from Admin. No need the code of overriding it.

[Ctucker9233]

@shahankitb997 @veloraven When I dug around in Magento\Framework\Stdlib\DateTime\DateTime, I noticed that there is supposed to be an offset created so that everything in the backend will display the proper local time. This offset seems to be broken or not used for some things. I believe it would fix the problem if that offset was also used in the newsletter queue.

[shahankitb997]

@Ctucker9233 So what will be the solution or quick fix for this one?

[Ctucker9233]

@shahankitb997 I wish I had an answer for you. I haven't had time really to play with it. I have read in other issues of this type that changing the 'UTC' in date_default_timezone_set('UTC'); to your specific timezone code will temporarily fix the issue. But this modifies core code and would be overwritten in the case of an update or upgrade. @veloraven please give us some feedback and let us know that this issue is being taken seriously and what its priority level is. Ideally it's a one or two line fix so that the newsletter module inherits the correct timezone offset. Please advise.

[shahankitb997]

Hi @Ctucker9233 & @veloraven Any updates on this?

[Ctucker9233]

@shahankitb997 I've got nothing. I'm actually not affiliated with Magento so I have no way of knowing.

[shahankitb997]

Thanks. @Ctucker9233 for reply.

HI @veloraven any updates?

[shahankitb997]

Does anyone have update on this one?

Thanks

[shahankitb997]

Any updates?

[Ctucker9233]

@shahankitb997 I'm not sure that @veloraven is a real person. He/she never responds.

[shahankitb997]

Hi @Ctucker9233 so who is concern i need to report to?

[Ctucker9233]

I've used @magento-admin and @magento-team with some success. In fact, if whoever is monitoring these tags reads this, we would appreciate a response.

[shahankitb997]

@magento-admin & @magento-team Any updates?

[J96]

Are more people having this issue? I have the exact same issue on Magento 2.1.3. The server, php and mysql time are set to Amsterdam. In the backend the locale is set to Amsterdam. However the time difference is 9 hours.

[Ctucker9233]

@J96 Yes, still have this problem. I'm on version 2.1.4. I believe it is messing with my cron jobs as well. They "look" like they run ok, but I am unable to do basic things like send newsletters and automatic re-indexing. I have to run these jobs manually in CLI and only then does it actually work.

[Ctucker9233]

@magento-team @magento-admin @magento-devops A little attention on this issue please!

[renatoaloi-tbf]

I am experiencing similar problem here, using locale timezone for Brazil. Running Magento CE ver. 2.1.6.

For me the impact is when I want to know if the user has logged out.

I am getting this output:

Date time now: 24-04-2017 18:44:55
Last Login time: 2017-04-24 18:36:39
Last Logout time:
Last Visit time: 2017-04-24 18:36:43

When running getCurrentStatus() at \Magento\Backend\Block\Template\PersonalInfo

The real date time at the moment of test was 04/24/2017 15:44:55

[veloraven]

We already have internal ticket for this issue: MAGETWO-56349

[magento-engcom-team]

@shahankitb997, thank you for your report.
The issue is already fixed in 2.2.0

[Ctucker9233]

@magento-engcom-team Please backport to 2.1 or mark as up for grabs.

[spotmarketing]

I am not sure what you mean by back port to 2.1 or mark as up for grabs? Can you provide documentation to do this. thanks Jason On October 30, 2017 at 6:57:36 PM, Ctucker9233 (notifications@github.com) wrote: @magento-engcom-team <https://github.com/magento-engcom-team> Please backport to 2.1 or mark as up for grabs. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7560 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AfpkLDbZOga5L8w2AH1R072SYnGKErIcks5sxlRfgaJpZM4K8C-v> .

[spotmarketing]

I have searched and I can not find how to do a backport or how to “Mark up for grabs”. I did find this ticket #8470 Which may be a similar issue. I see that it was updated with a fix. Will that fix my issue? Please provide some direction. We a couple days from launching the site and this is a huge set back. Thanks Jason Jason Smith *CEO* *Spot Marketing Group* p: 519.303.1154 Ext. 110 m: 226.268.0064 f: 519.303.1153 a: 132 Thames St. N. Ingersoll, ON N5C 2T4 w: www.spotmarketing.ca e: jsmith@spotmarketing.ca <https://www.facebook.com/SpotMarketingG/> <https://twitter.com/spotmarketingg> <https://ca.linkedin.com/in/jason-smith-99240a63> [image: Inbound Certification] [image: HubSpot Certification] [image: Inbound Sales Certification] [image: Partner Certification] <http://hubs.ly/H035cNn0> <http://offers.spotmarketing.ca/art-of-social-selling> On October 30, 2017 at 6:58:48 PM, Jason Smith (jsmith@spotmarketing.ca) wrote: I am not sure what you mean by back port to 2.1 or mark as up for grabs? Can you provide documentation to do this. thanks Jason On October 30, 2017 at 6:57:36 PM, Ctucker9233 (notifications@github.com) wrote: @magento-engcom-team <https://github.com/magento-engcom-team> Please backport to 2.1 or mark as up for grabs. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7560 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AfpkLDbZOga5L8w2AH1R072SYnGKErIcks5sxlRfgaJpZM4K8C-v> .

[Ctucker9233]

@spotmarketing I was asking the Magento team to backport it or mark it up for grabs. Since the original issue was reported against 2.1 it should be fixed in 2.1 in my opinion. Unless you are part of the Magento team, this isn't likely something you can do.

[spotmarketing]

Thanks but I am looking for an answer on this. It is not fixed in 2.1 and we are unable to launch the site because of this issue. How to I go about getting a resolution on this? Thanks Jason Jason Smith *CEO* *Spot Marketing Group* p: 519.303.1154 Ext. 110 m: 226.268.0064 f: 519.303.1153 a: 132 Thames St. N. Ingersoll, ON N5C 2T4 w: www.spotmarketing.ca e: jsmith@spotmarketing.ca <https://www.facebook.com/SpotMarketingG/> <https://twitter.com/spotmarketingg> <https://ca.linkedin.com/in/jason-smith-99240a63> [image: Inbound Certification] [image: HubSpot Certification] [image: Inbound Sales Certification] [image: Partner Certification] <http://hubs.ly/H035cNn0> <http://offers.spotmarketing.ca/art-of-social-selling> On December 14, 2017 at 4:58:38 PM, Ctucker9233 (notifications@github.com) wrote: @spotmarketing <https://github.com/spotmarketing> I was asking the Magento team to backport it or mark it up for grabs. Since the original issue was reported against 2.1 it should be fixed in 2.1 in my opinion. Unless you are part of the Magento team, this isn't likely something you can do. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7560 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AfpkLItR0zbcyWy8Qjwkn9pnNKtVXuG5ks5tAZoNgaJpZM4K8C-v> .

[Ctucker9233]

@spotmarketing You would have to look at the commits listed in this issue thread and cherry pick it into your magento version. That's the only way I would know how to resolve it right now. I just hope @magento-engcom-team is listening and will backport this to a 2.1 version sometime soon.

[roma-glushko]

Hi Guys!
Please don't remove date_default_timezone_set('UTC'); from the bootstrap file. This would not fix your data inconstancy, but let Magento shows data in "right" way.

Basically, Magento 2 uses CURRENT_TIMESTAMP as the default value for most of data fields (like created_at/updated_at). To check what is your current timestamp, you can execute the following SQL query:

SELECT CURRENT_TIMESTAMP;

As a result, we would see date in the default server timezone. However, Magento 2 expects to see it in UTC and that's good if your server/database timezone in UTC, but if it's not, you would get this issue.

So please make sure that system stores data in UTC in your database. If not, please make it so, and then Magento 2 would work with dates as expected.

The downside is 3rd-party that are not locale into account, but this is kind of different story.

Hopefully you find this experience helpful :)

[stephenbori]

For anybody who is having a timezone construct admin error on their magento 2.3.0 admin once logging in post upgrade from Magento 2.2.6 (similar to this)

Http error
magento Stdlib/DateTime/Timezone.php(199): DateTimeZone->__construct('')

Magento_log
[2018-12-11 16:42:46] main.ERROR: DateTimeZone::__construct(): Unknown or bad timezone () [] []

The easiest workaround is to check that your admin_users table are all using the interface local of your default store. My users where set to use en_US when actually my stores timezone and language where all set to en_GB

Once manually updating the database records for each user re-run bin/magento setup:upgrade

[netzwelt-nishu]

Hi All,

I am using Magento 2.3.0 and still facing issue regarding Order Date after migration from Magento 1. Can any body suggest me a working solution for this issue.

[ganonbit]

+1 on having this issue still on Order Date from Mage 1 to Mage 2 (2.2.6)

bootstrap.php shows UTC

config > locale options set to "America/Chicago" and last order should be 3pm and it's showing 1am.

[onepack]

Server Time is correct (Europe/Amsterdam), PHP is correct (Europe/Amsterdam).
Magento2 is set to Europe/Amsterdam.
However Time is always off with one hour.
It's now 22:29 but magento will tell me it's 21:29.
This is on 8 M2 installations with PHP 7.2 and Magento 2.3

[toledosteve]

Why is this issue closed, yet people are still experiencing the issue??

[netzwelt-nishu]

Hi,

Do anyone have any solution for the issue so far...? i upgraded to Magento 2.3.1 but issue is still there.

[stephenbori]

@netzwelt-nishu - are you using different timezones for admin users i.e en_US en_GB? - If so as a work-around try and set all your admin users to use the same timezone as your default store

[Adplabscode]

Someone found a solution?
Magento 2.2.6

[mihaifaget]

Problem still exists in 2.4. Even the logs have the wrong timezone...but someone thinks it's ok to close this and hide it under the carpet.
cron schedules at 12:00:00 and gets missed at 11:00:00, the same difference between magento timezone and utc.

[chdzma]

The error persists in Magento 2.3.5, Timezone Europe/Madrid in php.ini and Magento configuration and the confirmation request emails are seen with a 2h delay

EDIT: I have solved it by saving a custom configuration for each Website and not using the global value.

[neddy236]

Random Fix that worked for our instance.

Make sure the app/bootstrap.php is UTC -> date_default_timezone_set('UTC');
Go to admin -> stores -> configuration -> general -> locale options
Change the timezone to something random and save.
Change it back to your original timezone.

Not really sure what went down, but that actually fixed it.

[cptX]

Any news about this? Why is such an important issue closed???
It is unacceptable to have the logs in UTC time!!
Thousand things cannot work correctly like this, for example fail2ban!!! Also for human debugging wrong timezone is really bad!!
How can we set the correct timezone in logs?
Also, why is date_default_timezone_set('UTC'); line in bootstrap.php necessary?

@neddy236 I tried to change the timezone to another > save and then set it to my timezone but nothing changed!

[MilenV]

Hello @cptX @chdzma @neddy236 @onepack @zonaidev @roma-glushko @shahankitb997

We are experiencing strange issue on Production LIVE environment with Adobe Commerce ver. 2.4.5-p2
If you Go to Stores -> Configuration.
Make sure the Store View is set to: Default Config.
Go to General -> General.
Scroll down to Locale Options you will notice the timezone is GMT(Greenwich Mean Time Europe/London) which is identical on Staging and Production when compared manually.

and as per wiki https://experienceleague.adobe.com/docs/commerce-admin/marketing/promotions/cart-rules/price-rule-cart-scheduled-changes.html?lang=en this below is how price rule cart scheduled changes were set.

Friday morning the UK better than black friday the Homepage was supposed to go live however it did not go live at the time it was scheduled to go live (10:00am). This was then manually updated. An hour later the homepage updated to to the template that was originally supposed to go live at 10:00 because of this I tested on the UK dummy page for the page to go live at 12:30 and found that the homepage updated an hour later at 1:30 meaning that the scheduling times were out by an hour. This issue is also not happening on staging. Other scheduling live banners and promo codes worked correctly. It seams to only be on happening on the live pages

This is how the Homepage scheduling was set up, this is how all homepages have been set up - I think that there could possibly be an issue regarding the timing of Magento in the back end. This is the only thing that i could possibly think could have caused this issue.

Regards,
Milen Velinov