• Hello Fabrik Community

    Fabrik is now in the hands of the development team that brought you Fabrik for Joomla 4. We have recently transitioned the Fabrik site over to a new server and are busy trying to clean it up. We have upgraded the site to Joomla 4 and are running the latest version of Fabrik 4. We have also upgraded the Xenforo forum software to the latest version. Many of the widgets you might have been used to on the forum are no longer operational, many abandoned by the developers. We hope to bring back some of the important ones as we have time.

    Exciting times to be sure.

    The Fabrik 4.0 Official release is now available. In addition, the Fabrik codebase is now available in a public repository. See the notices about these in the announcements section

    We wish to shout out a very big Thank You to all of you who have made donations. They have really helped. But we can always use more...wink..wink..

    Also a big Thank You to those of you who have been assisting others in the forum. This takes a very big burden off of us as we work on bugs, the website and the future of Fabrik.

dates backing up one day when there is a form error

skyrun

Active Member
seeing a weird thing and i'll post in case someone else is seeing it and it's not something in my code.

when a form is processed and i run a validation script and return an error, the dates in the form are backing up one day... this (as far as i know) just started recently when i updated to the latest git.

form is passing me the correct dates, but if i send back an error, the form model looks like this:

5/15 is the date i typed, but after the error, dates go to 5/14. another error... 5/13 etc.

anyone seen anything like this? ring a bell on some new change that went in to the date plugin?

element has not changed (local date, m/d/y format for list and form, no time)
 

Attachments

  • formDataErr.PNG
    formDataErr.PNG
    5 KB · Views: 27
another screen shot... weird... (or shocking as my developer puts it).

NOTE that this is showing a date_enh element plugin that uses a uikit calendar, but the same thing happens using the fabrik date element plugin.
 

Attachments

  • shocking.PNG
    shocking.PNG
    16.6 KB · Views: 28
i'm ready to suggest that this a fabrik bug in date processing (most likely date.js)

see https://testlocation.skyrun.com/testing-date
(or testlocation.skyrun.com and click on 'testing date' menu item) no logon required, avail to public.

type or select any date and press save a few times. first time is ok... 2nd+ time, the date creeps back one day each time. this is a new form with one element of date type. to cause the form error (which is what causes the date back-creep) i have a plugin on the form onBeforeProcess that says:

$formModel->errors['test___date'][] = '.';
$formModel->getForm()->error = 'Simulated error on form to see if date stays put or goes back one day';
return false;

that's it... all else is std. tried it on a virgin protostar template and same thing.
 
tried advanced format, utc and local store date as, Y-m-d and m/d/y as format for list and form. all do same thing.

interesting new tidbit... adding the time selector = yes moves the TIME back 6 hours every time i save... so every 4 saves the day also moves back. 00:00:00 -> 18:00:00 -> 12:00:00 -> 06:00:00 -> back a day.

why 6? my mysql db timezone is UTC+6 AND my joomla timezone is UTC+6. one of both of those is causing this.
 
I've noticed some weirdness in J! date handling recently, which seems to affect us if the PHP timezone is different to Joomla's. May not be what is causing what you are seeing, but try setting your PHP tz to the same as Joomla.

Sent from my HTC6545LVW using Tapatalk
 
thanks for the response, but hope that's not it. i have joomla's in 4 different tz's on my server, so can't configure php to match each of them.

my php tz was UTC (the default). but i changed it to the same (America/Denver) for a test but does the same thing.

at least i think i changed it... i can't say i understand why php info on joomla system info says UTC one place and date.timezone is America/Denver (date.timezone is what i changed in php.ini from 'UTC' to 'America/Denver':

date/time support enabled
"Olson" Timezone Database Version 0.system
Timezone Database internal
Default timezone UTC
date.default_latitude 31.7667
date.default_longitude 35.2333
date.sunrise_zenith 90.583333
date.sunset_zenith 90.583333
date.timezone America/Denver
 
Last edited:
Issue is that dates have a 00:00:00 added to their end (even when it's a format without time). Then that is then being converted for joomla timezone. since 00:00:00 UTC is the day before everywhere except in UTC... the date only element only works for joomla timezone set to UTC. if you set your joomla timezone to anything else, you will get this issue of days backing up one (and times backing up the number of hours from UTC you are).

For our case when form is not submitted due to errors then time is changing to time zone offset.
  • As our reservation form don't have time so displayDate() has $gmt as
  • ValidDate . 00:00:00 (2017-04-24 00:00:00)
  • Line #379 $this->shouldApplyTz() is true due to $formModel->hasErrors() (line #426 and 443)
  • When shouldApplyTz() is true then it is changing 00:00:00 time to 6 Hours back which results date-1 day
OUR SOLUTION changing plugins/fabrik_element/date/date.php:

Possible solutions
- $gmt passing to function displayDate($gmt) should contain valid timeString
OR (this is what we did)
- $this->shouldApplyTz() should be false for case when $formModel->hasErrors(). This can be achieved by:
  1. commenting line #426
  2. and activating #427
  3. and removing $formModel->hasErrors() from line #443
 
Last edited:
The problem with both those approaches is I can guarantee they will break other use cases. I've spent literally hundreds of hours tweaking that code to handle every permutation of settings, and I pretty much know exactly what will break, as I remember what I was doing when I added that code.

I think the problem is more likely to be in getValue(), which is supposed to make sure that the time is always "normalized" to GMT, so we know where we're starting from in the rest of the (mind bendingly complex) code.

What *should* happen is that the date should get the TZ offset "unapplied" (set to GMT) in getValue(), so (say) if you are CST, the date (with no time format) submits as 00:00:00, the getValue() code (around line 1098) should remove the offset, so it become 05:00:00 (GMT), then the TZ offset gets applied again after the shouldApplyTz() in displayDate(), and the time goes back to 00:00:00.

And that's what happens for me, with my "no_time" test date. So I'm 99% sure the problem on your element is that getValue() isn't "normalizing" the time to GMT.

Looking at the code (1089) I suspect it may be that I have "default to today" set, and you don't? Although tbh, I don't know why we would look at "default to today", iirc that should only affect how the date is defaulted on a new record.

-- hugh
 
Last edited:
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top