Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Quoting myself from #2881791: Computed field value for DateTime field causes start time validation error:
Also, note that there's another problem here: because the date field stores no timezone, the promotion start/end dates are always specific to the customer's timezone. If you specified June 1st - June 10th assuming the EST timezone, and I'm in the GMT timezone, then the promotion will start earlier for me than for someone who's in EST. We could solve this by having a $store->timezone that's used for these things.
There's the same problem with taxes. If your tax changes from 18% to 19% on June 1st, do you switch when it's June 1st to the store, or June 1st to the customer? Cause if it's a US store, the EU customer will reach June 1st first, for example.
Logic says "June 1st to the store, since the store reports taxes", though I wonder if there will be potential confusion for the customer who'll see their invoice date be May 31st.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 2883789-7-store-timezone.patch | 46.74 KB | bojanz |
| #6 | 2883789-6-store-timezone.patch | 37.23 KB | bojanz |
| |||
| #5 | 2883789-5-store-timezone.patch | 16.29 KB | bojanz |
| |||
| #3 | store_timezone-2883789-3.patch | 7.2 KB | Nils Loewen |
| #2 | create_timezone_field-2883789-2.patch | 6.72 KB | shabana.navas |
| |||
Comments
Comment #2
shabana.navas CreditAttribution: shabana.navas at Acro Commerce commentedPatch that adds a base default timezone field to the store entity.
Comment #3
Nils LoewenGreat work Shabana.
I changed all defaults of 'UTC' to DateTimeItemInterface::STORAGE_TIMEZONE, which happens to be 'UTC', but use of the constant will be better in the long run.
Before writing tests for this, a new feature should be added which is a toggle on promotionListBuilder to show dates in store timezone or current user timezone, or for that matter, in storage timezone or site default timezone.
We should probably wait till #2977618: Add time to promotion start and end date is committed before adding that feature.
Comment #4
bojanz CreditAttribution: bojanz at Centarro commentedTime to finish this. We'll need it before proceeding with #2977618: Add time to promotion start and end date.
Committed #3093784: Add the concept of an order "calculation date" which should help.
Comment #5
bojanz CreditAttribution: bojanz at Centarro commentedHere's part 1.
Adds the $store->timezone field and converts commerce_tax to use it. The promotion part is yet to come.
I started from the patch in #3 and renamed "default_timezone" to "timezone", cause I felt that the "default_" prefix was unnecessary.
I also made the field default to the site timezone, and not UTC, since that's more user friendly
Comment #6
bojanz CreditAttribution: bojanz at Centarro commentedHere's part 2.
Promotions are now also converted.
Introduced StoreDateTimeWidget and StoreDateTimeFormatter, which respect the store timezone logic (and can be used by both commerce_promotion and commerce_pricelist). Currently still missing test coverage for them.
We're also missing the normalizer/denormalizer, but I'll leave that for a followup.
Comment #7
bojanz CreditAttribution: bojanz at Centarro commentedThis should be the final patch.
Adds test coverage for the new widget and formatter, and fixes a few warnings in them along the way.
Comment #8
bojanz CreditAttribution: bojanz at Centarro commentedBetter title.
Comment #10
bojanz CreditAttribution: bojanz at Centarro commentedCommitted.