Time and date picker adjusts time based on timezone

[galingong]

Description

time_picker field would adjust the value displayed in the field based on OS/browser timezone ie. will not display the value stored in the DB, but treats that value as if it was UTC and the displayed value was local. Value in store is correct so it should be something related to frontend/flatpickr.js.

Edit: date_picker with time is also affected.

Steps to reproduce

Set your OS timezone to something other than UTC and compare DB stored value and the field.

Expected result

No timezone adjustment

Actual result

Value in field offset by timezone

Versions

Twill version: 2.3.0
Laravel version: 10

[galingong]

It's probably because in DatePicker.vue on line 152 date-fns.parse is called with date + 'Z' and format + 'X' so the parsed value would be offset. Removing the Z (and since it's not needed anymore, also the X from format) seems to resolve the issue.

Edit: Had to also edit flatpickr format on line 135 to dateFormat: self.enableTime ? 'Y-m-d H:i' : 'Y-m-d' to completely resolve the problem.

[ifox]

The offset is intended to improve the user experience. Dates should always be stored in UTC in the database, but you don't want your users to have to do mental gymnastics with timezones when using date and time pickers in the CMS.

Are you reporting a bug with this implementation, or is it more that you were looking to disable that behavior?

[galingong]

To be honest, at the point when I opened this issue I was completely oblivious to the fact that it was good practice to store UTC dates in the DB - answering your question - it's not a bug if you followed best practices, so we might as well close this. But still it would be nice to be able to store and display datetime values independently from timezones. Do you have an idea if it would be possible currently?

[ifox]

I don't think it's possible currently without overriding a bunch of things. It should be possible to make this an optional feature, but we prefer pushing for best practices by default.

[jonw-cogapp]

FWIW I've seen crop up recently, and found a patch from someone else which aims to addresses this.

In both cases these were sites that moved from Twill 2 -> Twill 3. The behavior I describe below isn't something I can produce in Twill 2.

Observations (before I knew fully what was happening):

• The content editor will consistently see the correct dates on index pages if that field is surfaced there
• Front-end visitors consistently see the correct dates
• The content editor may see incorrect dates in the edit page, depending the timezone of the machine (e.g. My timezone is London and everything is fine, but if I change to Los Angeles in my OS settings and restart the browser I can trigger this). In such cases:
  • Viewing an edit page with a date field value of: "2023-06-22 00:00:00" may show "June 21, 2023"
  • Choosing "June 21, 2023" will always save "2023-06-21 00:00:00"
  • Reloading that page again may show "June 20, 2023"

I think for content editors working on event dates, this can be very confusing.

[galingong]

@jeffchown I ended up migrating my DB so that dates are UTC, set config/app timezone to UTC and I handle time-zones every time I do something with those datetimes. I guess this is the only way that it works properly.

[jeffchown]

@galingong Thanks for the quick response!

That's the way my app is already setup (re: UTC in both places).
For me, the issue arises when I have a column in my table that is date only (vs. datetime).

For my example, assume my browser's timezone is set to UTC -4 (America/Toronto).

Let's say the date in my database table is called scheduled_on and is set to 2026-01-22.

When Twill initializes a form for that record (in the admin area), it:

• interprets that value as 2026-01-22T00:00:00.000000Z
• adjusts it for my browser's timezone (-4)
• shows it in the form field as 2025-01-21 which is of course incorrect

Is there any way I can 'intercept' the value before the form is shown, so I can adjust the value manually to accommodate for the browser's timezone?

[jeffchown]

It wouldn't be an issue if the Twill date_picker, when the withTime attribute is set to false, would simply truncate/ignore the time component of the string, and skip any timezone conversion. But such is not the case :(

[galingong]

@jeffchown Ah, right, I get it, it's bad. It hasn't occured to me yet that it can cause that since I'm @ UTC+1/+2 so normal date fields haven't produced any errors for me yet. Now there are a couple of points I'd like to bring up on this topic:

(@ifox I'd be glad if you could share your thoughts on the 3rd point if you had the time)

• At this point I'd say it's a bug, since the date picker field doesn't work without time if the browser timezone is set on the western hemisphere. I think this should be reported.

• As for a workaround for your specific case, depending on which Twill version you're on, if you use Twill 3, accessors will work in the admin - so defining an admin_scheduled_on property (protected function adminScheduledOn(): Attribute {...}) on the model should work for you. You may also need to handle the value in prepareFieldsBeforeSave in the repository, or maybe use the passedValidation and offsetSet methods in the request class if you face issues storing the value. If you're still on Twill 2, as far as I remember you can override the form method on the controller, pass in data to the form_data key and from that you can define a form field in the view (eg. set $form['form_fields']['admin_scheduled_at'] = $item->scheduled_at->addHours(4), and define a date_picker with the name admin_scheduled_at). I think these two hacks should work.

• Why the repository getFormFields override didn't work for you - I did some digging around in the source code and if you checked the form field views (views/partials/form/_date_picker.blade.php), you can see that on line 26 $item->$name is preferred over $formFieldsValue. The latter is actually not a defined variable in this case because of the order of conditions in the @unless on line 22. This is just a bit strange, I find it odd that the view would parse the property from the model directly instead of using a value from the $form_fields array that's already prepared by the developer potentially. I don't really have an idea why this part works like this, but the pattern can be observed in other form views as well, not just the date picker. Might be worth it do ask the devs.

[jonw-cogapp]

@jeffchown Not ideal, however one option is using cweagans/composer-patches to target the datepicker vue component.

YMMV, I think specifically this second diff might be different for the most recent tag in Twill 3.

index d2a09f99..0bd11fc0 100644
--- a/frontend/js/components/DatePicker.vue
+++ b/frontend/js/components/DatePicker.vue
@@ -149,11 +149,11 @@
           parseDate: function (date, format) {
             const fullFormat = 'yyyy-MM-dd HH:mm:ss';
             if (date.length === fullFormat.length) {
-              return parse(date + 'Z', fullFormat + 'X', Date.UTC());
+              return parse(date, fullFormat, Date.UTC());
             }
             const fullFormatNoSeconds = 'yyyy-MM-dd HH:mm';
             if (date.length === fullFormatNoSeconds.length) {
-              return parse(date + 'Z', fullFormat + 'X', Date.UTC());
+              return parse(date, fullFormat, Date.UTC());
             }
             const fullFormatNoTime = 'yyyy-MM-dd';
             if (date.length === fullFormatNoTime.length) {

diff --git a/frontend/js/components/DatePicker.vue b/frontend/js/components/DatePicker.vue
index d2a09f99..0bd11fc0 100644
--- a/frontend/js/components/DatePicker.vue
+++ b/frontend/js/components/DatePicker.vue
@@ -132,7 +132,7 @@
           wrap: true,
           altInput: true,
           altFormat: self.altFormatComputed,
-          dateFormat: self.enableTime ? 'Z' : 'Y-m-d', // This is the universal format that will be parsed by the back-end.
+          dateFormat: self.enableTime ? 'Y-m-d H:i:S' : 'Y-m-d', // This is the universal format that will be parsed by the back-end.
           static: self.staticMode,
           appendTo: self.staticMode ? self.$refs[self.refs.flatPicker] : undefined,
           enableTime: self.enableTime,