Datetime and TZ inconsistencies

[NekoiNemo]

Attempted Debugging

• I have read the debugging page

Searched GitHub Issues

• I have searched GitHub for the issue.

Describe the Scenario

I have the following issues and can't seem to figure out if this is a bug or a misconfiguration:

1. When mousing over elements to get the exact dates - they are in UTC regardless of user's actual TZ. Now, they are correct (as in - this is the correct UTC time of the action), the "n units ago" is calculated correctly, they are stored in the database correctly, but the exact timestamp is shown in the UI without respect for user's TZ, and without indication that time is being displayed in UTC
2. The way the exact timestamp is displayed is inconsistent:

• For comments (as well as in Audit Log, User's last login and most other places) it displays good nice ISO timestamp:
  
• For books/pages it is displayed as such:
  
  
• And for Recent Activity column on the left - there's no popup with a timestamp at all

Exact BookStack Version

v23.12.1

Log Content

No response

Hosting Environment

Docker container (from LSIO) behind NGINX

  server:
    image: lscr.io/linuxserver/bookstack:latest
    environment:
      TZ: UTC
      APP_TIMEZONE: UTC
      APP_LANG: en
      APP_AUTO_LANG_PUBLIC: false

  db:
    image: lscr.io/linuxserver/mariadb:10.11.5
    environment:
      TZ: UTC

Host server is also in UTC (though it's locale isn't bound into containers)

[ssddanbrown]

Thanks for raising @NekoiNemo.

bug or a misconfiguration

Based upon what you've detailed, probably neither but instead a UX & consistency issue, and there's three things we should probably do:

• Update existing exact time tooltips to show in a consistent way.
  • We'd need to decide the best option for this.
• Ensure exact time tooltips are available on all areas where relative times are shown in-browser.
• Reflect the timezone within those hover exact time tooltips.

The last point might be tricky, as I'm not sure we may specifically know the original timezone of a timestamp if the admin changes the configured timezone. I'd have to re-review how dates are stored and the interplay with timezone. Still might be better to just reflect the current configured timezone though since the otherwise worst case is maybe +/-24 hours of error, around the rare case someone changes their timezone.

[bgartenmann]

Hi @ssddanbrown
I don't know how much you have looked into the timestamp/timezone issue already. We do have a rare/special case regarding this: We are operating two ships sailing around the world and have BookStack installed on both of them. They will travel through many different time zones within a year and we try to have our different systems reflect the current time zone they are in.
I haven't found a way to dynamically set the time zone in BookStack running in a docker container.
Other applications are using the "host" (container) time zone and for these I was able to mount the host time zone files into the docker container.
Maybe something like this would be possible for the last point above as well?

[ssddanbrown]

@bgartenmann You could create a script to update the timezone value used for BookStack based on system timezone, but that won't fully solve the scenario since (from what I remember) the setting applies to both storage and display and is not intended to be changed frequently. There's various different options to address things there, but I'd consider that outside the scope of this specific issue (which is specifically focused on presentation).

[bgartenmann]

@ssddanbrown You are right that this is out of scope of this issue. Thanks for the tip with the script, I will look into that.

[ssddanbrown]

Within #5790 I have now aligned time displays to be much more consistent.

As part of those changes, I have also split the timezone option out, so the existing APP_TIMEZONE option is used to define the timezone used for date storage in the database (generally best for this to be UTC) and a new APP_DISPLAY_TIMEZONE option can be defined to separately specify the timezone used for absolute time display in-app. This should provide a little extra flexibility and help avoid some issues when it comes to updating the app/display time.

Absolute dates shown in-app will now also include the short-format timezone indicated (UTC, BST etc...)

These changes will be part of the next feature release.