[#20271] - Calendar field adding incorrect time.
- Closed
- 10 May 2018
- Medium
- Build: 3.8.7
- # 20271
I have a custom component. One of the back end edit views has a standard Joomla calendar field with the following xml format:
<field
name="date"
class="inputbox"
format="%d-%m-%Y %H:%M"
timeformat="24"
filter="user_utc"
default="NOW"
minyear="-1"
maxyear="1"
showtime="true"
singleheader="false"
todaybutton="false"
weeknumbers="false"
filltable="true"
type="calendar"
required="true"
label="COM_BDPROPERTYMANAGER_FORM_LBL_BOOKING_DATE"
description="COM_BDPROPERTYMANAGER_FORM_DESC_BOOKING_DATE"
hint="COM_BDPROPERTYMANAGER_FORM_LBL_BOOKING_DATE"
/>The issue I have is that when a date and time is saved, the time in the database is one hour behind. Therefore the time on the front end of the site is shown as one hour behind. This has occurred due to British Summer Time. Server time is correct and the Joomla global time is set to "London".
Steps to reproduce the issue
Create a custom component with a calendar field.
Expected result
The correct date and time is saved to the database.
Actual result
The wrong time is saved to the database (one hour previous).
System information (as much as possible)
Joomla 3.8.7
Linux Server
Apache
PHP 7.2.4
10.1.31-MariaDB-cll-lve
Additional comments
I have searched around for this issue and found this dated from 2013. I have tried removing the "filter" attribute and using filter="none" but this results in nothing at all being saved to the database. Also "server_utc" shows up the same issue (one hour previous).
Votes
franz-wohlkoenig
- | Category | Components | ⇒ | Components JavaScript |
| Status | New | ⇒ | Discussion |
filter=none should not cause anything to break in the saving process.
I have used that attribute value quite a few times in the components I have created.
Having filter set to none prevents what is stored in the database to have a timezone applied to it when read.
And it also prevents a timezone being applied to the date/time from the Calendar input when it is saved to the database.
I believe user_ut is an override to server_ut. So if your filter is set to user_ut and the logged in user does not have a custom timezone the system will fall back to the server_ut.
Joomla! saves dates/times in UTC.
So basically in your case you have a server_ut timezone of "London" which is +1 hour from UTC (GMT+1) so when Joomla! saves that date/time from the calendar it converts it to UTC (which is an hour less of London), that is what is in your database.
When you edit one of your components items, Joomla! will convert that saved UTC time into one based off the London timezone.
If you want to bypass that system, you set the filter=none.
Then exactly what you enter in the calendar is saved to the database.
Any items you have created or edited prior to switching the filter=none you will have to update, so what you put in the calendar is what gets saved.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20271.
| Status | Discussion | ⇒ | Information Required |
| Status | Information Required | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-05-10 14:37:20 |
| Closed_By | ⇒ | joomla-cms-bot |
| Closed_By | joomla-cms-bot | ⇒ | Quy |
Set to "closed" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/20271
Closing per the detailed answer.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20271.
I know this is closed but for me setting filter="none" does break things. And i can confirm this is because of the formatting i'm using (dutch formatting). filter none works fine if your formatting is set to 0000-00-00. But since i'm dutch and we use 00-00-0000 it doesn't get saved to the DB field if your DB Field type is set to DATE. So setting filter to "none" is not a solution to the problem for many people. What i think should be the fix is having joomla check if the field has the time option set and if so, ignore any timezone conversion because it should never convert any timezone at all.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20271.
The calendar essentially should accept only a js formated value, right now we're passing php formatted values, but that's a bit of hard B/C. Also manipulating the data from db or input seems to cause this behaviour. I did a PR to solve this: #17823
but it broke another part of the code. Essentially we need to drop most of our current code, standardise on the js format and then let everything else handled in the client side. We do have some extremely complicated code for some relatively straight forward field: calendar.