starred/SuiteCRM-SuiteCRM

Fork 0

mirror of https://github.com/SuiteCRM/SuiteCRM.git synced 2026-03-02 19:16:58 -05:00

DateTime fields inside templates rendered as Dates #3310

New issue

Closed

opened 2026-02-20 16:03:41 -05:00 by deekerman · 11 comments

deekerman commented

2026-02-20 16:03:41 -05:00

Owner

Originally created by @Jorilx on GitHub (Sep 20, 2018).

The class responsible for rendering datetimes inside templates, include/SugarFields/Datetime/SugarFieldDatetime.php, looks for the format to use with

$user_dateFormat = $timedate->get_date_format();

instead of

$user_dateFormat = $timedate->get_date_time_format();

so if you use a datetime inside a *viewdefs.php, it gets rendered as a date instead of a datetime.
Is this by design? Am I missing something?

I'm on SuiteCRM 7.10.8 but this call has been there from the "beginning" :)

Originally created by @Jorilx on GitHub (Sep 20, 2018). The class responsible for rendering datetimes inside templates, `include/SugarFields/Datetime/SugarFieldDatetime.php`, looks for the format to use with `$user_dateFormat = $timedate->get_date_format();` instead of `$user_dateFormat = $timedate->get_date_time_format();` so if you use a datetime inside a `*viewdefs.php`, it gets rendered as a date instead of a datetime. Is this by design? Am I missing something? I'm on SuiteCRM 7.10.8 but this call has been there from the "beginning" :)

deekerman closed this issue

2026-02-20 16:03:42 -05:00

deekerman commented

2026-02-20 16:03:43 -05:00

Author

Owner

@pgorod commented on GitHub (Oct 3, 2018):

I am not sure this is related, but does this fix help anything?

https://suitecrm.com/suitecrm/forum/suitecrm-7-0-discussion/3265-datetime-field-wouldn-t-show-the-time-in-pdf-email-how-to-show-datetime-correctly-instead-of-showing-only-date#72440

@pgorod commented on GitHub (Oct 3, 2018): I am not sure this is related, but does this fix help anything? https://suitecrm.com/suitecrm/forum/suitecrm-7-0-discussion/3265-datetime-field-wouldn-t-show-the-time-in-pdf-email-how-to-show-datetime-correctly-instead-of-showing-only-date#72440

deekerman commented

2026-02-20 16:03:43 -05:00

Author

Owner

@Jorilx commented on GitHub (Oct 4, 2018):

Well the fix I mentioned in my post is enough for me, I was just wondering WHY SugarFieldDatetime looks for get_date_format instead of get_date_time_format :) Thanks for your help though!

@Jorilx commented on GitHub (Oct 4, 2018): Well the fix I mentioned in my post is enough for me, I was just wondering WHY SugarField**Datetime** looks for `get_date_format` instead of `get_date_time_format` :) Thanks for your help though!

deekerman commented

2026-02-20 16:03:43 -05:00

Author

Owner

@pgorod commented on GitHub (Oct 4, 2018):

Do you want to make a PR to add your fix to the SuiteCRM code?

@pgorod commented on GitHub (Oct 4, 2018): Do you want to make a PR to add your fix to the SuiteCRM code?

deekerman commented

2026-02-20 16:03:43 -05:00

Author

Owner

@Jorilx commented on GitHub (Oct 4, 2018):

I'll try, thanks! :D

@Jorilx commented on GitHub (Oct 4, 2018): I'll try, thanks! :D

deekerman commented

2026-02-20 16:03:43 -05:00

Author

Owner

@samus-aran commented on GitHub (Nov 30, 2018):

Hey @Jorilx
`$user_dateFormat = $timedate->get_date_format();
if (!empty($vardef['value']) && !$timedate->check_matching_format($vardef['value'], $user_dateFormat)) {

        $sdt = $timedate->fromString($vardef['value'], $current_user);

        if (!empty($sdt)) {
            //the new 'date_formatted_value' array element will be used in include/SugarFields/Fields/Datetime/DetailView.tpl if it exists
            $vardef['date_formatted_value'] = $timedate->asUserDate($sdt, $current_user);
        }
    }`

From looking at the code it appears that the get_date_format is only used to find out the user's preferences i.e. d/m/y or m/d/y which is needed to just 'confirm' that the value can be converted later
at this point $vardef['date_formatted_value'] = $timedate->asUserDate($sdt, $current_user);
So the point that you are really questioning is.... https://github.com/salesagility/SuiteCRM/blob/master/include/TimeDate.php#L674

@samus-aran commented on GitHub (Nov 30, 2018): Hey @Jorilx `$user_dateFormat = $timedate->get_date_format(); if (!empty($vardef['value']) && !$timedate->check_matching_format($vardef['value'], $user_dateFormat)) { $sdt = $timedate->fromString($vardef['value'], $current_user); if (!empty($sdt)) { //the new 'date_formatted_value' array element will be used in include/SugarFields/Fields/Datetime/DetailView.tpl if it exists $vardef['date_formatted_value'] = $timedate->asUserDate($sdt, $current_user); } }` From looking at the code it appears that the get_date_format is only used to find out the user's preferences i.e. d/m/y or m/d/y which is needed to just 'confirm' that the value can be converted later at this point $vardef['date_formatted_value'] = $timedate->asUserDate($sdt, $current_user); So the point that you are really questioning is.... https://github.com/salesagility/SuiteCRM/blob/master/include/TimeDate.php#L674

deekerman commented

2026-02-20 16:03:43 -05:00

Author

Owner

@samus-aran commented on GitHub (Nov 30, 2018):

Perhaps looking at https://github.com/salesagility/SuiteCRM/blob/master/include/TimeDate.php#L613
AsUser returns datetime field types which uses the get_date_time_format()

@samus-aran commented on GitHub (Nov 30, 2018): Perhaps looking at https://github.com/salesagility/SuiteCRM/blob/master/include/TimeDate.php#L613 AsUser returns datetime field types which uses the get_date_time_format()

deekerman commented

2026-02-20 16:03:43 -05:00

Author

Owner

@Jorilx commented on GitHub (Dec 6, 2018):

I'm not sure of what's going on, but my situation is the following:
using Studio I've added the "date_modified" field to the Accounts EditView, and if I leave SugarFieldDatetime.php as it is, the field gets rendered just as a date. If I apply my patch, it gets rendered correctly as datetime.
As a workaround I've found that I can leave SugarFieldDatetime.php alone if I specify
'customCode' => '{$fields.date_modified.value}' inside metadata/editviewdefs.php.
I'll try and investigate the issue further, thanks for your time!

@Jorilx commented on GitHub (Dec 6, 2018): I'm not sure of what's going on, but my situation is the following: using Studio I've added the "date_modified" field to the Accounts EditView, and if I leave SugarFieldDatetime.php as it is, the field gets rendered just as a date. If I apply my patch, it gets rendered correctly as datetime. As a workaround I've found that I can leave SugarFieldDatetime.php alone if I specify `'customCode' => '{$fields.date_modified.value}'` inside metadata/editviewdefs.php. I'll try and investigate the issue further, thanks for your time!

deekerman commented

2026-02-20 16:03:44 -05:00

Author

Owner

@Jorilx commented on GitHub (Dec 6, 2018):

I'm sorry, but isn't it odd that a function that's trying to render a datetime calls asUserDate? Moreover, the comment for asUserDate is Format DateTime object as user date so I'd be inclined to believe that the intention behind the code is really to render it as just a date... I'm quite confused 😄

@Jorilx commented on GitHub (Dec 6, 2018): I'm sorry, but isn't it odd that a function that's trying to render a **datetime** calls asUser**Date**? Moreover, the comment for asUserDate is `Format DateTime object as user date` so I'd be inclined to believe that the intention behind the code is *really* to render it as just a date... I'm quite confused :smile:

deekerman commented

2026-02-20 16:03:44 -05:00

Author

Owner

@samus-aran commented on GitHub (Dec 18, 2018):

Can we close this @Jorilx? This an issue or have we got a work around?

@samus-aran commented on GitHub (Dec 18, 2018): Can we close this @Jorilx? This an issue or have we got a work around?

deekerman commented

2026-02-20 16:03:44 -05:00

Author

Owner

@Jorilx commented on GitHub (Dec 18, 2018):

Well I think that the original behaviour is "unexpected" and someone else could be bitten by this problem in the future, but the customCode workaround works so it's not an issue for me anymore.

@Jorilx commented on GitHub (Dec 18, 2018): Well I think that the original behaviour is "unexpected" and someone else could be bitten by this problem in the future, but the customCode workaround works so it's not an issue **for me** anymore.

deekerman commented

2026-02-20 16:03:44 -05:00

Author

Owner

@cameronblaikie commented on GitHub (Apr 5, 2019):

Hi @Jorilx ,
I'm unable to replicate this issue on hotfix or latest LTS. Please let me know if this is still an issue you can replicate and we will investigate further.
Thanks.

@cameronblaikie commented on GitHub (Apr 5, 2019): Hi @Jorilx , I'm unable to replicate this issue on hotfix or latest LTS. Please let me know if this is still an issue you can replicate and we will investigate further. Thanks.

deekerman referenced this issue

2026-02-20 16:05:14 -05:00

Email Template Not Replacing Contact/Lead/Target Name Variable in Leads #3423

deekerman referenced this issue

2026-02-20 16:09:36 -05:00

Open Backlog - Sprint 12 Planning [7.8.x EOL] #3764

deekerman referenced this issue

2026-02-20 16:10:11 -05:00

Previous Sprint (13) #3812