Closed (fixed)
Project:
Commerce Core
Version:
8.x-2.x-dev
Component:
Promotions
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
19 Apr 2021 at 02:19 UTC
Updated:
12 Oct 2022 at 11:39 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
bojanz commentedPromotion start/end dates are in the store timezone, not UTC.
Can you confirm that the timezone of your store is set properly?
Commerce doesn't use the site timezone because different stores can be in different timezones.
Comment #3
mandclu commentedThanks for the suggestion. I checked and the store was indeed set to use the same timezone as the site, in my case -0400 (Toronto).
Comment #4
bojanz commentedThanks for confirming.
Does the bug you're seeing mean that the promotion doesn't become active for customers at the given start date in the store timezone, or is it a UI bug where the default value for the start date in the admin UI isn't what you expect?
Comment #5
mandclu commentedIt's the latter. As an admin, I would expect that if I don't alter the promotion's start date, it would start right away. Instead, the form is populated with a default value that seems offset by the timezone.
Comment #6
bojanz commentedUnderstood.
Since a promotion can be available in multiple stores, we don't have access to a store and its timezone, but we can at least use the site timezone for the default value.
Comment #7
igor.barato commentedIf we look the node "Authored On" field, it follows the Default site timezone.
I believe we can follow the same approach on Default start date value.
I replaced the gmdate() function by date() to work with the Site timezone.
Comment #9
bsuttis commentedHere's a patch to change PromotionTest to use date() instead of gmdate().
Comment #11
bsuttis commentedCouponTest too.
Comment #12
damienmckennaCustomer was complaining that the start time shown on the add-promotion form was using the wrong timezone, after some debugging I worked out the problem was that neither the site nor store timezone was being used to convert the time generated from UTC, which lead me to search the issue queue for "promotion timezone", which lead me to this issue. And the patch solves the problem perfectly.
Comment #14
jsacksick commentedCommitted, thanks.
Comment #16
drumm(Updating to fix Drupal.org issue indexing issue, please disregard.)