Conversion of 2018-08-04 23:44:59 from user format d/m/Y h:ia failed

berghy · 26 September 2018 01:20

I am getting the following error hundreds of times in my suitelog.
Wed Sep 26 12:43:02 2018 [12817][1][ERROR] fromUser: Conversion of 2018-08-04 23:44:59 from user format d/m/Y h:ia failed
The locale and user are both configured as d/m/Y and 11:20pm.
I am using Suitecrm 7.10.7. Any ideas why ?

pgr · 26 September 2018 12:49

It might be coming from your Scheduler Jobs. Is it happening every minute, or with another regular time pattern?

Scheduler Jobs rely on a different PHP (CLI - command-line) and they require different configuration in another php.ini

Check your CLI effective timezone with this

php -i | grep timezone

And use this to know where the relevant php.ini is located:

php -i | grep php.ini

berghy · 28 September 2018 00:48

Thanks pgr. I think you are right. Unfortunately I am on a shared server and the cli php.ini file is locked for me.

pgr · 28 September 2018 09:45

Ask your hosting about alternatives.

Often they will allow options to be set from CPanel, other times they let you put a small php.ini in your area, and it will get picked up, filtered and applied within certain restrictions.

It is well within your “basic rights” to have your cron jobs run with an appropriate timezone.

If necessary your cron entry can also be adjusted to pass a date.timezone through the command-line.

sieberta · 30 November 2018 18:11

I’m getting similar errors, seemingly resulting from Workflow (not CLI, onSave rather). And my php.ini seems to be set to the correct timezone.

The errors:

Thu Nov 29 15:35:03 2018 [18050][1][ERROR] fromUser: Conversion of 2018-10-26 20:32:32 from user format m/d/Y H:i failed
Thu Nov 29 15:35:03 2018 [18050][1][ERROR] fromUser: Conversion of 2018-11-29 21:35:02 from user format m/d/Y H:i failed
Thu Nov 29 15:35:03 2018 [18050][1][ERROR] fromUser: Conversion of 2018-10-26 20:32:32 from user format m/d/Y H:i failed
Thu Nov 29 15:35:03 2018 [18050][1][ERROR] fromUser: Conversion of 2018-11-29 21:35:02 from user format m/d/Y H:i failed
Thu Nov 29 15:35:03 2018 [18050][1][ERROR] fromUser: Conversion of 2018-10-26 20:32:32 from user format m/d/Y H:i failed
Thu Nov 29 15:35:03 2018 [18050][1][ERROR] fromUser: Conversion of 2018-11-29 21:35:02 from user format m/d/Y H:i failed
Thu Nov 29 15:35:03 2018 [18050][1][ERROR] fromUser: Conversion of 2018-10-26 20:32:32 from user format m/d/Y H:i failed
Thu Nov 29 15:35:03 2018 [18050][1][ERROR] fromUser: Conversion of 2018-11-29 21:35:02 from user format m/d/Y H:i failed
Thu Nov 29 15:35:10 2018 [18057][1][ERROR] fromUser: Conversion of 2018-10-26 20:32:32 from user format m/d/Y H:i failed
Thu Nov 29 15:35:10 2018 [18057][1][ERROR] fromUser: Conversion of 2018-11-29 21:35:10 from user format m/d/Y H:i failed
Thu Nov 29 15:35:10 2018 [18057][1][ERROR] fromUser: Conversion of 2018-10-26 20:32:32 from user format m/d/Y H:i failed
Thu Nov 29 15:35:10 2018 [18057][1][ERROR] fromUser: Conversion of 2018-11-29 21:35:10 from user format m/d/Y H:i failed
Thu Nov 29 15:35:10 2018 [18057][1][ERROR] fromUser: Conversion of 2018-10-26 20:32:32 from user format m/d/Y H:i failed
Thu Nov 29 15:35:10 2018 [18057][1][ERROR] fromUser: Conversion of 2018-11-29 21:35:10 from user format m/d/Y H:i failed
Thu Nov 29 15:35:10 2018 [18057][1][ERROR] fromUser: Conversion of 2018-10-26 20:32:32 from user format m/d/Y H:i failed
Thu Nov 29 15:35:10 2018 [18057][1][ERROR] fromUser: Conversion of 2018-11-29 21:35:10 from user format m/d/Y H:i failed

In a debug session, note that user is ‘null’ although, userid is ‘1’. I wondered if that is because there sortof isn’t a user when workflow is calling the code?

pgr · 1 December 2018 11:02

User id “1” is admin.

I am not sure if the code should have a loaded “user” object at that point, perhaps you can try it to see if it solves anything?

holdusback · 13 June 2019 13:03

For the people who are wondering from what its from.

I’ve noticed that the modified date of my custom module update everytime I go in the detail view of a custom module, without a good time :

If I enter a detailview at 14h55 it will modify the modified hour to 12h55.

And I will have this in my log :

Thu Jun 13 14:52:44 2019 [16521][1][ERROR] fromUser: Conversion of 2019-01-10 14:40:26 from user format d/m/Y H:i failed
Thu Jun 13 14:52:44 2019 [16521][1][ERROR] fromUser: Conversion of 2019-06-13 12:52:44 from user format d/m/Y H:i failed
Thu Jun 13 14:52:44 2019 [16521][1][ERROR] fromUser: Conversion of 2019-01-10 14:40:26 from user format d/m/Y H:i failed
Thu Jun 13 14:52:44 2019 [16521][1][ERROR] fromUser: Conversion of 2019-06-13 12:52:44 from user format d/m/Y H:i failed
Thu Jun 13 14:56:43 2019 [17719][1][ERROR] fromUser: Conversion of 2019-01-10 14:40:26 from user format d/m/Y H:i failed
Thu Jun 13 14:56:43 2019 [17719][1][ERROR] fromUser: Conversion of 2019-06-13 12:56:43 from user format d/m/Y H:i failed
Thu Jun 13 14:56:43 2019 [17719][1][ERROR] fromUser: Conversion of 2019-01-10 14:40:26 from user format d/m/Y H:i failed
Thu Jun 13 14:56:43 2019 [17719][1][ERROR] fromUser: Conversion of 2019-06-13 12:56:43 from user format d/m/Y H:i failed

ashish · 13 June 2019 15:01

That is some old PHP bug I believe , which PHP version are you at?

holdusback · 14 June 2019 07:49

After some inspection, its deeper than this…

Customized the opportunities module, in view.detail.php I’ve got some custom code, at the end of this code I got a bean->save().

$this->bean->save();

Thats the real issue. IDK why, $this->bean->save() change the date format… that’s the cause of my issue, saving on the detail view with $this->bean->save().

I’ve done that :


        print_r ('Date créa' .$this->bean->date_entered);
	$this->bean->save();
	print_r ('Date créa apres' .$this->bean->date_entered);

And the result is :

Date créa 20/11/2018 15:57
Date créa apres 2018-11-20 14:57:03

The first one is completely OK, its the good french format. the sec one, after the save is the “bugged” one.

Actually I’m trying to fix that, IDK really how I will do, im digging into the forum to see if someone got the same issue, maybe its a bug directly from suiteCRM.

pgr · 14 June 2019 08:48

It’s normal for the Bean to store date in database format, with UTC timezone and american format. The local format should only be applied at the moment of display to user.

These date functions are tricky and you need to know what SuiteCRM expects when you fill that field programmatically.

Are you setting the date yourself, inside this custom code you have? Please show any previous code that you have that handles that date field.

holdusback · 14 June 2019 09:06

Not a all, its just addition of field (to make a grand total) and showing in the opportunity some related thing to the account (some accounts relationship)

Nothing about date. But thanks for your answer.

In my detailviewdef.php, i’ve got, like all my other module this code about the date format :

'LBL_PANEL_ASSIGNMENT' => 
    array (
      0 => 
      array (
        0 => 
        array (
          'name' => 'date_entered',
          'customCode' => '{$fields.date_entered.value} {$APP.LBL_BY} {$fields.created_by_name.value}',
        ),
        1 => 
        array (
          'name' => 'date_modified',
          'label' => 'LBL_DATE_MODIFIED',
          'customCode' => '{$fields.date_modified.value} {$APP.LBL_BY} {$fields.modified_by_name.value}',
        ),

My user preference are OK, all my other module are save the date correctly.

pgr · 14 June 2019 09:44

I am not sure about this, but I think what is happening is that you are in a display class and your bean is already a bean processed for display, so it has a local date_entered. But that gets interpreted differently when you try to save it.

Maybe you need something in your code to look at

fetched_row['date_entered']

and see if it’s different from $this->bean->date_entered.

There are auxiliary functions that you might need

$timedate global variable
to_db
to_display_date_time

These will also help you search Google for examples. Good luck and tell us your final solution when you solve it! Thanks

holdusback · 14 June 2019 09:48

Thanks PGR for the help, Im going for a more easy way : Make my field not quick editable, so the user have to pass by the editview, I’ve put my code in view.edit.php :

<?php
if (!defined('sugarEntry') || !sugarEntry) {
    die('Not A Valid Entry Point');
}
require_once('modules/Opportunities/views/view.edit.php');

class CustomOpportunitiesViewEdit extends OpportunitiesViewEdit
{
     public function __construct(){
        parent::__construct();
     }

    function display()
    {
        //call parent display method
        parent::display();
		
		//Cumul Annuel 
		$cumul = $cumul + $this->bean->janvier_c;
		$cumul = $cumul + $this->bean->fevrier_c;
		$cumul = $cumul + $this->bean->mars_c;
		$cumul = $cumul + $this->bean->avril_c;
		$cumul = $cumul + $this->bean->mai_c;
		$cumul = $cumul + $this->bean->juin_c;
		$cumul = $cumul + $this->bean->juillet_c;
		$cumul = $cumul + $this->bean->aout_c;
		$cumul = $cumul + $this->bean->septembre_c;
		$cumul = $cumul + $this->bean->octobre_c;
		$cumul = $cumul + $this->bean->novembre_c;
		$cumul = $cumul + $this->bean->decembre_c;
		
		//Save le cumul
		$this->bean->cumulannuel_c = $cumul;
		$this->bean->save(); // Useless ???
		}
}
?>

t.lesca · 14 June 2019 14:08

Hello,

I also have a date conversion issue but it seems to me that it’s on graph dashlet.
“Fri Jun 14 15:47:44 2019 [28559][1][ERROR] convert: Conversion of 14/06/2019 17:00 from Y-m-d H:i:s to d/m/Y H:i failed”

I do not know if it will help but in case.

PS : Je suis également français ^^

holdusback · 17 June 2019 13:01

Got to add that it is from the workflow module.

I’ve deleted all my custom code and the issue is still there. My log is full of thoses failed conversion.

Got a workflow on save of every Opportunities, I think the bug come from Workflows directly.

Salut T.Lesca !

pgr · 18 June 2019 11:33

You are right that any Opportunity Workflow will produce this error in the logs.

Do you see any wrong behaviour connected to this message? Or is it just a misleading log message? I am wondering if this actually affects anything, namely the decision to execute the Workflow or not.

This is the part of the code that is calling that function that gives the error:
https://github.com/salesagility/SuiteCRM/blob/master/modules/AOW_WorkFlow/AOW_WorkFlow.php#L627-L649

The two variables beanDataEntered and beanDateModified are the ones that possibly have unexpected values…

holdusback · 5 July 2019 13:30

I’ve got some custom script that import oppotunity from CSV file, everytime I import I got 2 of this log lines by line in my CSV… Really annoying

The strange thing is that the date is correctly saved when I go check in my oppotunity module (day/month/year hour:minute)

pgr · 8 July 2019 17:48

That’s a similar problem to the one fixed here:

https://github.com/salesagility/SuiteCRM/pull/7323/files

If you can tell PHP not to output any errors in that part of the code, you should be ok.

Have a look at all the PHP output control functions: https://www.php.net/manual/en/ref.outcontrol.php

And perhaps also display_errors parameter which you can set with ini_set() function.

jrawoot · 5 September 2019 16:21

Hi holdusback,
How can I save bean in edit view?
$this->bean->save(); is this work for you?

jrawoot · 5 September 2019 16:23

Hello pgr,
How can I set any bean value in view.edit.php?
I have trying below code but it is not working

$this->bean->department = "Developement";
$this->bean->save();