Datepicker saves wrong date (1 day back)

[ma]

When creating a new 'task' under 'plans' (/artefact/plans/new.php?id=xxxxx) or editing a task (/artefact/plans/edit/task.php?id=xxxx) the date i select for 'completion date' is being saved incorrectly.

I select '2019/10/31' in the datepicker.
The input field shows '2019/10/31' correctly.
After I click 'save task' it then shows '2019/10/30' in the task overview. (which is one day before my selected date)

This only happens when I select a date which is in winter time (Winterzeit MEZ: UTC+1)
It doesn' happen when I select a date which is in summer time (Sommerzeit MESZ: UTC+2)

Under siteconfiguration i have set country and timezone correctly.

I can imagine thatthe problem is somewhere in the conversion to UTC, but i dont know how to fix it in my case.

[Robert Lyon (robertl-9)]

Hi mafen,

Are you able to check the database and see if the date is being saved correctly or not?

Please check the "completiondate" column of the "artefact_plans_task" table - is it being saved as previous day at database level?

- if it is then it'll be a read / display at browser level problem

but

- if it isn't then can I get you to check the timezone and offset values on the database.

You'll need to login to the database with the values that the Mahara logs in with

For postgres

you can get the timezone: SELECT current_setting('TIMEZONE');
and offset: SELECT EXTRACT(TIMEZONE FROM now())/3600.0 AS tz_offset;

For mysql

you can get the timezone: SELECT @@global.time_zone, @@session.time_zone;
and offset: SELECT TIMESTAMPDIFF(HOUR, UTC_TIMESTAMP(), NOW()) AS tz_offset;

Cheers

Robert

[ma (mafen1)]

Hello Robert,

thank you for your quick answer!

I checked the "artefact_plans_task" table and ist shows: 2019-10-31 00:00:00
This seems correct to me.

So it is just a display issue. It happens in different browsers for different users.

Any idea how to fix this?

[Cecilia Vela Gurovic (ceciliavg)]

I could not replicate this error.

I tried changing the timezone in the database and also the OS, but could not see any issues.

We might need a bit more information to try to replicate. What DB to use postgres/mysql and version. Also the OS and browser it's failing on

[ma (mafen1)]

We are still on Mahara Version 19.04.0 (2019031906) and we are still having this problem.

@Robert
SELECT @@global.time_zone, @@session.time_zone;
Output: SYSTEM/SYSTEM
SELECT TIMESTAMPDIFF(HOUR, UTC_TIMESTAMP(), NOW()) AS tz_offset;
Output: 2

"date" command on server shows:
Do 16. Jul 14:59:26 CEST 2020
This is the correct time here right now.

Infos about database: SHOW VARIABLES LIKE "%version%";

innodb_version: 5.5.61-MariaDB-38.13
protocol_version: 10
version: 5.5.65-MariaDB

Client OS: Windows 10 Enterprise 1909 (but also other Win10 non Enterprise and earlier Versions)

Browser:
Chrome Version 83.0.4103.97
Firefox 78.0.2
Microsoft Edge
(but also earlier Versions)

Like i said before:

This only happens when I select a date which is in winter time (Winterzeit MEZ/CET UTC+1)
It doesn' happen when I select a date which is in summer time (Sommerzeit MESZ/CEST UTC+2)

For example saving 2020/07/16 works correctly.
But saving 2020/11/16 ends up showing as 2020/11/15 after saving.

[Robert Lyon (robertl-9)]

Hi mafen

The patch for another fix relating to plans / tasks may have fixed this issue

https://reviews.mahara.org/#/c/10501/7

As it had some code relating to the 'Europe/Berlin' timezone that has now been removed

It was relating to a Mahara function getCurrentTerm()

So maybe alter the code to avoid using that function and see if that makes a difference

Cheers

Robert

[ma (mafen1)]

Hello Robert,

this sounds promising, but I couldn't apply the patch as the whole structure in htdocs/artefact/plans seems to have changed in the last year. I don't even have a directory htdocs/artefact/plans/tools or a PlansTools.php

No problem, we will see how it works after our next upgrade.