Thanks - and yup, this has fixed it.

Going from:

NULL DEFAULT \'0000-00-00 00:00:00\'

to:

NULL DEFAULT CURRENT_TIMESTAMP

Thanks :-)

The error_log schema you're seeing is correct. We switched that field to TIMESTAMP a while back because TIMESTAMP values are stored in UTC, making them timezone-independent, which is what we wanted for error log entries. This means that when the server's timezone changes, the dates are automatically adjusted. In contrast, DATETIME stores fixed dates without timezone conversion.

This issue could have occurred if:

• A backup file containing an old error_log structure was restored
• The schema file wasn't properly uploaded (though yours appears to be current)
• The upgrade code somehow failed

To fix this:

1. Edit the dateLogged field and save it to trigger the custom column checking update:
/cmsb/admin.php?menu=database&action=editField&tableName=_error_log&fieldname=dateLogged

2. Verify the correct column type appears in the MySQL Source tab: `dateLogged` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
/cmsb/admin.php?menu=database&action=editTable&tableName=_error_log&fieldSaved=1#tab_mysqlSource

Note: We included code in version 3.77 to handle this conversion automatically, so if this issue persists, please let me know and we'll investigate further.

Thanks for reporting this! Please confirm if the above solution works for you.

Yeah I wondered that.

The MySQL type for the dateLogged field is, as reported on admin.php?menu=database&action=editTable&tableName=_error_log is

datetime NOT NULL DEFAULT 0000-00-00 00:00:00

and in the schema file:

  'dateLogged' => [
    'customColumnType' => 'TIMESTAMP DEFAULT CURRENT_TIMESTAMP',
    'label' => 'Date',
    'type' => 'date',
    'isSystemField' => 1,
    'defaultDate' => '',
    'defaultDateString' => '',
    'showTime' => 1,
    'showSeconds' => 1,
    'actualColumnType' => 'datetime NOT NULL DEFAULT \'0000-00-00 00:00:00\'',
  ],

And all the entries in the MySQL table have dateLogged (and updatedDate) as 0000-00-00 00:00:00.

I see in other schema files, system date fields are:

  'updatedDate' => [
    'type' => 'none',
    'label' => 'Last Updated',
    'isSystemField' => '1',
  ],

So is there perhaps an issue with our schema config for _error_log.schema.php?

This install was recently upgraded from a very old verison (a good year + old) to 3.76 and then 3.77.

Cheers

Rob

The dateLogged field is a timestamp database field with a default of the current timestamp. You shouldn't need to set it in the code as MySQL will set it at time of insertion. Are you seeing this with all the error log entries or just certain log entries? Did it just start with your upgrade to v3.77?

Additional information may help us track down the reason. Perhaps somewhere a date is being inserted that is bad and so MySQL is setting it to null or some other value that equates to the UI showing "never". 

Note: If you have the developer console plugin enabled, you could query the error_logs table and see if there are bad values in the dateLogged table. Might offer a clue. :)

Errors logged into _error_log are being inserted without a dateLogged, so they appear as "never" in the UI, as per attached screenshot.

Looking at

function errorDB_addErrorRecord($colsToValues):

and

function _errorlog_logErrorRecord

the dateLogged variable is not set anywhere within either of those.

Would likely make best sense to set it in the:

 //  create log record data
$colsToValues = [

errorlog_functions.php line 313

Cheers!

Rob