In the application logs, I receive "2021/12/08 17:01:43 [error] [application.LimeExpressionManager] setVariableAndTokenMappingsForExpressionManager with an empty surveyOptions." when trying to change the theme. I've also tried a few different date formats (including the removal of the creationDate xml element) in configs.xml, but nothing seems to work.

We couldn't reproduce it in master with postgre. Can you try again please with the steps you provided?

Is the error happening with new surveys or with pre-existing surveys?

Thanks!

Hi Gabriel, the error happens with new and existing surveys. I've also noticed it happens when I try to save other survey properties as well, such as settings in the Publication and Access tab (Link survey on public index page), settings in the Presentation tab (Show "There are X questions in this survey"), etc.

The lime_surveys.datecreated field in our Postgresql database is a timestamp of the form YYYY-MM-DD 24H:MM:SS.fff. For example, 2021-11-11 18:11:32.000 2021-12-15 20:38:52.000 2021-11-25 23:30:14.000.

I've been able to side-step the GUI error by making manual changes to the database fields thus far.

changing public index page setting 2022-01-11 112659.png (16,806 bytes)   

changing public index page setting 2022-01-11 112659.png (16,806 bytes)   

dbeaver date created 2022-01-11 113646.png (26,819 bytes)   

dbeaver date created 2022-01-11 113646.png (26,819 bytes)   

Can I please ask you a screenshot of the definition of the startdate and datecreated fields in the database?
Also, does this happen when you update something on an active survey? or only to deactivated surveys?

Can I also ask you to add this line (temporary) on application/controllers/admin/database.php, line 922

Yii::log("Trying to save with this date " . $oSurvey->datecreated, \CLogger::LEVEL_ERROR, 'application.controller.database');

Like this.

image.png (44,322 bytes)   

image.png (44,322 bytes)   

Our thought is that somehow, the postgre DB saves the values with a precision of more than 3 digits on the timestamp.
After loading that value from DB and trying to save, that makes the validation rule to fail.

Here are the database definitions for the fields originating in the lime_surveys table.

It happens on active and deactive surveys.

Also, adding that line (using setFlashMessage instead of log) to database.php, we get "Trying to save with this date 11-JAN-22 23:01:46", see photo.

image-3.png (9,834 bytes)   

image-3.png (9,834 bytes)   

image-4.png (9,727 bytes)   

image-4.png (9,727 bytes)   

image-5.png (8,815 bytes)   

image-5.png (8,815 bytes)   

image-2.png (26,601 bytes)   

image-2.png (26,601 bytes)   

Thanks!

I think the issue is with some deault PHP/PDO option when picking up the date from the DB.
Will review

Does this help?
https://www.postgresql.org/docs/9.1/runtime-config-client.html#GUC-DATESTYLE
https://www.postgresql.org/docs/9.6/locale.html

I believe it is a DB / Locale setting issue.

Check the DateStyle parameter on the DB. That should be it.

Running "show datestyle;" gives me "ISO, DMY"

From https://www.postgresql.org/docs/9.1/datatype-datetime.html#AEN5595, it seems like this date from should work ("08-Jan-99 --> January 8, except error in YMD mode")

When querying, DB is returning dates on a style which is later not accepted by the validations done on LS.
DB will accept the values, but it is the app validations that are failing before getting to intent saving on the DB.

Please, try changing it. "SQL, DMY" may work

@gabrieljenik : https://github.com/LimeSurvey/LimeSurvey/blob/74f4ee3ee6b9632adff9a0c1bdae946f4eae4b86/application/models/Survey.php#L535

Seems rules accept 2022-01-11 23:01:28.000 ?

Else : maybe need fixed when show form ?

Adding "set datestyle to SQL, DMY" to the configs.php initSQLs array gives "Trying to save with this date 11/01/2022 23:01:46" with the same dateCreated error.

image-6.png (8,677 bytes)   

image-6.png (8,677 bytes)   

Then, ISO should be good.
Can I ask you to try changing locale settings? Maybe on windows itself?

maybe need fixed when show form ?

@DenisChenu I don't think so. This is an issue for dates when:

• model is loaded
• date is not updated
• model is saved
• rule fails.

Form is not involved I believe

Strangely : trying to save 11/01/2022 23:01:46 must broke on SQL and MARIADB too …

Else : we don't show datecreated in form … then you're right …

Using 'initSQLs'=>array(..., 'set datestyle to ISO, DMY'), in config.php seems to have solved this... "ISO, DMY" is the result of "show datestyle;" but it's also what I use in initSQLs...

image-7.png (6,103 bytes)   

image-7.png (6,103 bytes)   

Great! What do you mean by " I use in initSQLs"?

I just meant to say that "ISO, DMY" is the same datestyle in

configs.php

'set datestyle to ISO, DMY' in 'initSQLs'=>array(..., 'set datestyle to ISO, DMY')

and

postgresql

show datestyle;
ISO, DMY

So it's odd this changes anything, but I'm very happy this is working now!

Hello mhladun,
I checked this with the latest version and could not reproduce, so this is most likely fixed for good.
Therefore, I am closing this issue. If you still can reproduce the issue using the latest version, please feel free to re-open the issue.
Thank you!

galads