-
-
Notifications
You must be signed in to change notification settings - Fork 259
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When exporting a report the various dates within the report (e.g. calendar entries, time stamps) may differentiate from what the recipient sees. #4019
Comments
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) |
It usually reports day before as it is close to midnight. Calendar entry could be hardwired to YYYY-DD-MM. |
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. |
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).
The text was updated successfully, but these errors were encountered: