When exporting a report the various dates within the report (e.g. calendar entries, time stamps) may differentiate from what the recipient sees.

[elbill]

What version of GlobaLeaks are you using?

4.14.5

What browser(s) are you seeing the problem on?

All

What operating system(s) are you seeing the problem on?

Windows

Describe the issue

The extracted dates for calendar entries contain a random UTC time (9 or 10.00pm). For other dates it contains the actual dates and hours. When extracted the date may not correspond to the one stated in the report that is converted to the local one.

Proposed solution

I would suggest calendar entries to contain only dates and not precise time. Also when a report is exported to be extracted to the browser date/time zone (in addition the UTC could be also stated in brackets).

[evilaliv3]

Thank you @elbill for reporting this.

I will fix the templating system to drop the time printing showing only YYYY-DD-MM and siscarding the part HH:mm

Lets see if this will fix the situation fully or if we have some situations in which the user select a day but the print has some discrepancy (showing the day before or the day after)

[elbill]

It usually reports day before as it is close to midnight. Calendar entry could be hardwired to YYYY-DD-MM. The complexity would be with timestamps. It is worth trying to implement a local time export.

[evilaliv3]

I agree.

At the moment all is handled with timestamp and the patch that i've issud just remove the hour/minute.

As you say the best would be to correct the client to directly hardwire YYYY-DD-MM and remove any processing from the server. For retrocompatibility the server will just need to recognize that the data is already in this format and avoid to perform any processing and for when the data is an old timestamp we should perform the same processing that we do now.