Datetime and TZ inconsistencies #4417

New Issue

OVERLORD · 2026-02-05T08:50:56+03:00

OVERLORD commented

2026-02-05 08:50:56 +03:00

Originally created by @NekoiNemo on GitHub (Jan 19, 2024).

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:

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
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)

Originally created by @NekoiNemo on GitHub (Jan 19, 2024). ### Attempted Debugging - [X] I have read the debugging page ### Searched GitHub Issues - [X] 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: ![screenshot_1705673074](https://github.com/BookStackApp/BookStack/assets/3595771/d33aceb9-3ab4-420a-9bf5-cc4582f1ced7) * For books/pages it is displayed as such: ![screenshot_1705673002](https://github.com/BookStackApp/BookStack/assets/3595771/6d896383-56f7-41de-b9a0-0879e98321ad) ![screenshot_1705673070](https://github.com/BookStackApp/BookStack/assets/3595771/a48ac090-453c-4be1-90d5-abc7d0ccaf7f) * 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)

OVERLORD added the 🛠️ Enhancement label 2026-02-05 08:50:56 +03:00

OVERLORD closed this issue

2026-02-05 08:50:59 +03:00

OVERLORD commented

2026-02-05 08:51:04 +03:00

@ssddanbrown commented on GitHub (Jan 19, 2024):

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.

@ssddanbrown commented on GitHub (Jan 19, 2024): 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.

OVERLORD commented

2026-02-05 08:51:06 +03:00

@bgartenmann commented on GitHub (Jul 31, 2024):

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?

@bgartenmann commented on GitHub (Jul 31, 2024): 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?

OVERLORD commented

2026-02-05 08:51:10 +03:00

@ssddanbrown commented on GitHub (Jul 31, 2024):

@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).

@ssddanbrown commented on GitHub (Jul 31, 2024): @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).

OVERLORD commented

2026-02-05 08:51:12 +03:00

@bgartenmann commented on GitHub (Aug 2, 2024):

@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.

@bgartenmann commented on GitHub (Aug 2, 2024): @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.

OVERLORD commented

2026-02-05 08:51:13 +03:00

@ssddanbrown commented on GitHub (Sep 4, 2025):

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.

@ssddanbrown commented on GitHub (Sep 4, 2025): 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.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#4417