The getDefaultStartDate function in the Promotion class creates a formatted date string using the user's current timezone, rather than the datetime in the timezone of the store. That means that if promotions are created programatically without explicitly specifying the start date, the start date will only have the proper value if the user has the same timezone set as the store. If not, the resulting time string will be wrong, and may lead to hours-long delays before the promotion becomes active.
Similarly, when creating a promotion using the front-end create promotion form, the date time being entered into the database is in the user's timezone rather than the store timezone, so promotions do not start working at the time that the user has specified.
Closed: works as designed
3.0
Promotions
Oops, sorry, I've unintentionally hidden fork branches. Got them back again.
getDefaultStartDate() can't rely on the store timezone as there is no store set at this point.
Also changes were made several months ago, (See
#3209414: Promotion start date default value doesn't respect time zone →
).