Hi, you can close this request. The issue was that my Timezone was set to GMT. I changed it to eastern time zone and now it is ok. Since this is our development server, I forgot to change the default time zone. Thanks

Hello , debug mode is enabled
I see following lines in the burndown_syslog

2018-03-05T15:43:43+00:00 [31442] [info] Start calculating burndown 235
2018-03-05T16:43:43+01:00 [31442] [debug] Capacity: 10
2018-03-05T16:43:43+01:00 [31442] [debug] Original start date: 1519862400
2018-03-05T16:43:43+01:00 [31442] [debug] Duration: 10
2018-03-05T16:43:43+01:00 [31442] [debug] User Timezone: GMT
2018-03-05T16:43:43+01:00 [31442] [debug] Server timezone: Europe/Stockholm
2018-03-05T16:43:43+01:00 [31442] [debug] Start date after updating timezone: 1519858800
2018-03-05T16:43:43+01:00 [31442] [debug] Period is current
2018-03-05T16:43:43+01:00 [31442] [debug] Day cached: 2
2018-03-05T16:43:43+01:00 [31442] [debug] Period days: 3
2018-03-05T16:43:43+01:00 [31442] [debug] Period days without last computed value: 2
2018-03-05T16:43:43+01:00 [31442] [info] End calculating burndown 235

Thanks for the query,
You cache seems ok, can you check if the debug mode is enable on your platform?
in /etc/tuleap/conf/local.inc
$sys_logger_level = 'debug';

Once it's in debug mode, try to access to the artifact 235, you should have new debug lines
in burndown_syslog

Best regards

Below the results from the query:
mysql> SELECT * FROM tracker_field_computed_cache WHERE artifact_id = 235 \G

*************************** 1. row ***************************
artifact_id: 235
field_id: 712
timestamp: 1519945199
value: NULL
*************************** 2. row ***************************
artifact_id: 235
field_id: 712
timestamp: 1520031599
value: 50
2 rows in set (0.00 sec)

mysql>

In order to don't wait tomorrow,
if you provide me the result of following command:
SELECT * FROM tracker_field_computed_cache WHERE artifact_id = <ARTIFACT_ID>

I should be able to tell you if the issue came from your cache or not.

Best regards

The burndown_syslog does not correspond to any recent dates. Regarding your other questions, since I'm in the process of testing 9.18 I don't know if the issue exists for other burndown charts. On our Dev server there are no other projects with burndown. For me to reproduce the issue, I won't be able to provide you an answer till tomorrow.

I can't assure you that your burndown is not properly displayed due to the cache,
the force generation was to ensure me that the issue, is not due to a wrong cache.

I didn't ask you, do you have the problem on all your burndown, or is the issue related to
a specific burndown?
If the issue is present in all your burndown, the force cache generation is useless.
If it's related to a specific burndown, it might resolve the issue.

Hi Marie-Ange, I did not force cache generation. Do I need to? Is that why it is not being displayed properly?

Hello,

I will need more information:
- did you try to force cache generation of this burndown?

If yes can you provide me the logs of file burndown_syslog?

Best regards