The user profile can be used to configure the displayed date format.
When a user has set the date format to dd/mm/yyyy and the reminder module assumes mm/dd/yyyy it will not add an alert. Other date formats may also not work.
Setting the date format to yyyy-mm-dd or mm/dd/yyyy works ok.
Also see #2082
Alert should be triggered according to the reminder date time.
No alert is triggered.
Using the console enter the following
console.log("Alerts:", alertList.length, "Time:", secondsSinceLoad);
The output will show that the alert length is 0.
See below
Reminders do not occur.
The reminders module looks at the list of reminders, when the date and time of the reminder get close it will trigger an alert countdown to start.
There are a number of different date times within Suite from the various timezones, these are
When date time is compared one must ensure that date time read from the database directly is not compared to a date time from the SugarBean as this is comparing GMT based to User based date times.
In addition when using php date time functions these can be processed using the server date time. The current time would be in the server timezone and date time string processing uses the server date time settings.
For example the function strtotime converts a textual date time description into a Unix timestamp. If the server is using mm/dd/yyyy and the input string is dd/mm/yyyy errors will occur. For the 5th of Jan 2016 the timestamp will be for the 1st of May 2016 and for the 21st Jan 2016 a null timestamp will be returned as 21 is an invalid month.
In modules/Reminders/Reminder.php stored reminders are processed to see if the date time as arrived to create a countdown alert. This is done by the following code
strtotime($relatedEvent->date_start) >= strtotime(self::unQuoteTime($dateTimeNow)) &&
strtotime($relatedEvent->date_start) <= strtotime(self::unQuoteTime($dateTimeMax))
Both $dateTimeNow and $dateTimeMax are in database format (YYYY-MM-DD HH:MM:SS GMT). strtotime will work in this case.
$relatedEvent->date_start is from the bean and is in the User timezone and date time format. In this case if the user date format is set to dd/mm/yyyy the calculated timestamp will be incorrect.
Note that email reminders work, the code for this is
$remind_ts = $timedate->fromUser($eventBean->date_start)->modify("-{$reminderBean->timer_email} seconds")->ts;
$now_ts = $timedate->getNow()->ts;
if ($now_ts >= $remind_ts) {
In this case the bean date time string is converted to a DateTime object using the fromUser() function that takes into account the user settings and therefore operates correctly.
I am working on a fix for this which I will submit a pull request for.
The issue has been tested on recent version of SuiteCRM(7.7.4), and it appear,
We assign this issue as a bug.
@KhyberPass , thanks for raise this issue.
Is this somehow related to the fact that the Scheduler module doesn't seem to display times in the correct user format? I mean, in the list of scheduled tasks, the times shown in the Range column; and in the detail view of each task, the Last successul run and Execute time fields.
The information there always shows as mm/dd/yyyy. Also the hours there always show as am even when they are pm. This is confusing when you're trying to determine if your schedulers are running....
If this is entirely unrelated, I can open a different issue for it - but I'd like to ask first. Thanks.
Hi @pgorod The Reminders module is different to the Schedulers module so it would not be related.
The date and time displays correctly for me in version 7.4.3 and also the latest hotfix branch. The date and time are displayed using the User profile setting. I tried yyyy-mm-dd and dd/mm/yyyy and both displayed correctly.
What version are you running?
If it is still an issue for you I suggest you open a new issue.
@KhyberPass thanks for your reply. I'm running 7.7.4. Your answer made me go back and check and it was my user's date settings that I had wrong - I was quite convinced I had set them correctly, but I must have changed something else. Problem is fixed now : - )
I thought the two modules might be somewhat related because I see a Scheduled task called Run Email Reminder Notifications but I guess that's just one piece of a larger puzzle. Thanks.
Hi @vladbar just to let you know I have been working on this issue and are about to submit a pull request in the next few days. Just doing some final testing at the moment.
Nick
The proposed fix in PR #2539 appears to resolve the issue on our environment.
also an issue on 7.8.0
Stated to be resolved in 7.10.5 Please ask to be re-opened if this isn't the case!