[#7657] - User Profile: Date of birth should be absolute.
- Closed
- 10 Aug 2015
- Medium
- Build: staging
- # 7657
- Diff
- infograf768:dob
- Success The Travis CI build passed Details
User tests: Successful: Unsuccessful:
When using the Profile User Plugin, the date of birth entered and displayed should be independent from server or user settings.
Test instructions:
In Global Configuration set the Server Time Zone to Paris (Test done in France, use other values to test)
Enable User - Profile plugin
Edit com_contacts Options =>Contact tab and enable "Show Profile"
In back-end, create a contact and assign it to a user.
Edit the user profile:
1. Set the Time Zone to "Default" in Basic Settings tab
2. Set a Date of birth in "User Profile" tab with the calendar. I have set it to 1948-04-20 below.
3. Create a menu item to display this contact in frontend. Display the Profile tab or slider of that contact.
Before patch, the date of birth is wrong, it displays 1948-04-19:
After patch, as it takes off the server-utc filter, the date is correct.
Will prepare another patch to display the date in the correct language format (DATE_FORMAT_LC4), without the time, i.e. to get for French:
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Labels |
Added:
?
|
||
| Category | ⇒ | Front End Plugins |
| Title |
|
||||||
Have you tested that? In my instructions I specified to set the user time zone to "Default" and I evidently resaved the user profile each time I modified the global Server time zone.
When server set to Paris, dob entered as 1948-04-20 in the profile field through calendar or manually, I get in the frontend:
1948-04-19 23:00:00
Database contains also 1948-04-19 23:00:00
I tested also by setting the server to Moscow and I get
1948-04-19 21:00:00
To test your comment, I applied my patch, set the server to Moscow, the user to Paris, and re-entered the correct dob for the user profile.
It saves as "1948-04-20 00:00:00" in the db and displays as 1948-04-20 00:00:00 in front-end, which is what is expected.
We do have a bug, Thomas and my patch looks like working.
As coded, no filter does not mean it falls down to user_utc
See:
https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/form/fields/calendar.php#L175-L206
As coded, no filter does not mean it falls down to user_utc
You need to look a few lines above:
https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/form/fields/calendar.php#L125
$this->filter = (string) $this->element['filter'] ? (string) $this->element['filter'] : 'USER_UTC';
I haven't tested, but since I rewrote that calendar field sometimes ago, I think I know how it's supposed to work.
If it doesn't change the value of the date, then we actually have a bug there 
server_utc is the filter which is meant to not change the date since you are not expected to change that setting after you set up the server.
To test your comment, I applied my patch, set the server to Moscow, the user to Paris, and re-entered the correct dob for the user profile.
It saves as "1948-04-20 00:00:00" in the db and displays as 1948-04-20 00:00:00 in front-end, which is what is expected.
To test you should enter the date, and afterwards change the timezone of the user. AS long as the timezone is the same as when the value is entered, it will shown the same. It's when you change the timezone afterwards when it gets interesting
Hmm, yeah, if I change again the user_utc to Moscow, then it fails again.
We do have a bug indeed and imho we need to code a no-filter param for the date.
Nah, server_utc would work. As long as you don't change the server timezone.
Which there really is no point in changing after you setup the site. It's the whole purpose of that filter as I understand it.
We could create a new case:
case 'RAW':
// Keep the date as absolute.
if ($this->value && $this->value != JFactory::getDbo()->getNullDate())
{
$this->value = $this->value->format('Y-m-d H:i:s', true, false);
}
break;
and change filter to "raw"
I guess It would be B/C as the filter does not exist yet.
You would also have to change the part where it is rendered. Currently it should be JHtml::Date($date, $format, false). You would have to use JHtml::Date($date, $format, null) to output it as it is stored.
About the rendering, I was thinking of something like:
for components/com_contact/views/contact/tmpl/default_profile.php
+ case "profile_dob":
+ echo "<dd>" . JHtml::_('date', $profile->text, JText::_('DATE_FORMAT_LC4')) . "</dd>";
+ break;
+
and in components/com_users/views/profile/tmpl/default_custom.php
+ <?php if ($field->type == 'Dob') : ?>
+ <?php $field->value = JHtml::_('date', $field->value, JText::_('DATE_FORMAT_LC4')); ?>
+ <?php endif; ?>
BTW, I do confirm that using filter="server_utc" (i.e. no patch) displays a wrong date if the server is set to a UTC+ which is the case for Paris and Moscow for example.
Added the new filter and date formatting for the display.
forgot to update default_profile.php as it was behind staging. Trying to do now
On a sidenote: If you really want to have the date stored without any timezones applied, you can use filter="none" (or whatever you want actually) and it will not do anything with the value.
When showing the date, you still need to use JHtml::('date', $value, $format, null) or JHtml::('date', $value, $format, 'UTC') as I wrote above so you can apply proper formatting.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2015-08-10 06:27:14 |
| Closed_By | ⇒ | infograf768 |
Sorry, but that will make it even worse. By default the filter will be "USER_UTC", adjusting the date when showing to the timezone of the user.
Having the filter as "SERVER_UTC" works fine. The real issue is that you have changed that timezone after the first date has been entered.
If we really want to have this date stored as is, then we need to change the code so it isn't stored as UTC in the database and always shows as it was entered. I doubt you can do that in a B/C way.