Bug: jdate 'notempty' validation causing date to roll back to previous day (ajax)

[bggann]

I've got a form with a jdate field - only the date is used

Conditions:
- jdate field
- Default to 'today' (doesn't matter for this case)
- No time selector.
- Validation "notempty"
- Ajax validation on.
- Date stored as UTC
- Local timezone MST (6 hours off)

What happens it:
- You open a record existing - (this does not seem to happen on new record).
- You pick a date - say 1 day in the future.
- AJAX validation runs
- The date jumps back by one day, so if you pick 2021-09-23 you get 2021-09-22


Stepping through the code:
What is happening is:
- The date is set to "2021-09-23 06:00:00" I presume the 06: hour is because 00:00:00 UTC is 06:00:00 MST

In jdate.php function validate() (/* comments below are mine)

if ($this->app->input->get('fabrik_ajax', '0') === '1') /* is this ajax? In my case, yes.
{
if (FabrikWorker::isDate($data)) /* This returns true. $data='2021-09-23 06:00:00'
{
$params = $this->getParams(); /*$params is empty.
$localDate = $this->displayDate($data); /* data='2021-09-23 06:00:00'
/*displayDate returns
$localDate[date] = 2021-09-23 00:00:00.000000
/* Notice the 06: has been removed. This is done inside DisplayDate
/* by $date->setTimeZone($timeZone);

--> At this point the Date we are working with is 2021-09-23 00:00:00.000000

/* Rest of code executes normally but it returns the UTC Date.
----------------------

All great - but this code runs 2 times. On the second run, we are fed in 2021-09-23 00:00:00 so after "setTimeZone()" the date returned is "2021-09-22 18:00:00". 6 hours earlier.

So - the date field jumps back 1 day.
-> It looks like the tzcorrection is being applied 2 times inappropriately.

-----------------------
I'm looking into this - but this is a bit deeper than I can handle. So I wanted to document it. Maybe somebody else wants to tackle it.....
-Bob

 

[lousyfool]

What do you mean y "Local timezone MST (6 hours off)"? Is that J! global system timezone, or the one set in the J! user account?

If it's the first, it shouldn't be an issue, so I guess it's the latter?

And if it's the latter, then this is the same problem I'm facing in a project I've just started working on... so, seems you've just been a tad faster than me with bringing this up, haha.

What Fabrik is doing right (like the majority of other J! components, except fo K2 and some other baddies)
- if you set (j)date to "stored as UTC", as you did,
- and the user is guest,
- or the logged-in user's individual timezone (TZ) is set to "default" (= J! global system TZ as per J! Global Config) or the same TZ as J! global system TZ:
Then user enters date/time in system TZ, Fabrik stores it in UTC, and everywhere it's shown correctly in system TZ.

But, like with so many other components as well, it gets messy if the user is logged in and has a TZ set in his user account which is different from the global system one.

That's -- pretty obviously -- because, like so many others, Fabrik does not follow all the rules for a good TZ management in J!, so that e.g. for event timings and users all around the world everyone can see and set dates/times in their respective TZs.

To do this properly, with dates/times stored as UTC, Fabrik should do as follows:

1. By default (= guests), show dates/times everywhere (forms, lists, details, ...) in J! global system TZ, means offset UTC against J! system TZ. Well, AFAIK Fabrik does that already!
2. Otherwise, (= logged-in user), show dates/times everywhere offset UTC against user TZ (so, no matter what TZ users are set to, "default" or else, they'll always see and work with the correct dates/times). That's what Fabrik still needs.

Implementing that point #2 shouldn't be a biggie (in just few places just add a check if user is logged-in, and if so, offset UTC against the TZ in his J! user account params).

I'm still dealing with other stuff for my new project but, unless someone else is going to "fix" this small issue (it's really rather an "improvement" which makes really good sense to not deprive J! users of a great native feature), at some point in the near future I guess I'll give it a go myself. Just can't say when exactly (not to mention TZ differences, hahaha...).

 

[bggann]

lousyfool. Nope - not a user tz issue in my case. All my users are in Colorado - so we are all in MST and the global time zone is set to MST.
All my users are seeing this.
In my case - it really does seem related to validation correcting for tz two times on an ajax validation.
On ajax, it is working on the form data - which is local TZ. Because I have "Store as UTC" turned on - the validation does a correction (happens in displayDate) and returns UTC to the form $data. That may be appropriate for some TZ validations - but not-empty probably shouldn't care. But it does need to validate that the value is a valid date. The problem is that $data appears to be updated with the UTC value. Then it runs validation again (not sure why, but not unusual) and this time $data is already corrected for UTC. 2nd correction causes the problem.
It does not seem like validation should be changing the value in $data before submission. It seems that $data should be local time, but maybe not.
Anyway - not exactly what you are seeing.
-bob

 

[lousyfool]

Anyway - not exactly what you are seeing.

Yup, true that, you're experiencing a different thing.