[Bug]: Webhook timestamps show 16-hour time difference despite correct container timezone configuration #764

New Issue

OVERLORD · 2026-02-04T21:15:51+03:00

OVERLORD commented

2026-02-04 21:15:51 +03:00

Originally created by @brucexo on GitHub (Jul 25, 2025).

Where is the problem occurring?

I'm not sure

What browsers are you seeing the problem on?

Firefox, Microsoft Edge, Chrome

Current behavior

Description:

I'm experiencing a severe timezone issue with Planka webhooks where the timestamps returned have a 16-hour difference from my local time, despite proper timezone configuration.

Environment:

Planka version: v2.0.0-rc.3
Deployment: Docker Compose
Container timezone: (properly set and verified)TZ=Asia/Shanghai
Local time: CST (UTC+8)
Actual time difference: 16 hours (not the expected 8 hours for UTC/CST difference)

Desired behavior

Issue Details:

Container timezone is correctly configured:

docker exec -it env | grep TZ

Output: TZ=Asia/Shanghai

docker exec -it date

Output: Fri Jul 25 10:25:01 CST 2025

Webhook timestamps show 16-hour difference:

Local time: 10:25 AM CST
Webhook timestamp: Shows time that is 16 hours behind local time
This is not the standard 8-hour UTC/CST difference
Root cause identified:
The issue appears to be in line 83 where is hardcoded .env.sample:83 , overriding container-level timezone configuration.server/.env.sampleTZ=UTC

Network location tested:

Initially tested with server IP in Seattle, Washington
Changed to local network IP - 16-hour difference persists
Confirms the issue is not related to network/geographic location
Expected Behavior:
Webhook timestamps should either:

Respect the container's setting, orTZ=Asia/Shanghai

Show standard UTC time (8 hours behind CST, not 16 hours)
Actual Behavior:
Webhook timestamps consistently show a 16-hour time difference from local CST time, regardless of:

Steps to reproduce

Container timezone configuration
Network location/IP address
System time synchronization
Proposed Solutions:

Allow the application to respect the container's environment variable instead of hardcoded UTCTZ
Add a separate configuration optionWEBHOOK_TIMEZONE
Fix the underlying issue causing the abnormal 16-hour offset
Additional Context:
The 16-hour difference is unusual and suggests there may be a double timezone conversion or other calculation error in the webhook timestamp generation process. This significantly impacts webhook integrations that depend on accurate timestamps.

Allow the application to respect the container's environment variable instead of hardcoded UTCTZ
Add a separate configuration optionWEBHOOK_TIMEZONE
Fix the underlying issue causing the abnormal 16-hour offset

Other information

No response

Originally created by @brucexo on GitHub (Jul 25, 2025). ### Where is the problem occurring? I'm not sure ### What browsers are you seeing the problem on? Firefox, Microsoft Edge, Chrome ### Current behavior ### Description: I'm experiencing a severe timezone issue with Planka webhooks where the timestamps returned have a 16-hour difference from my local time, despite proper timezone configuration. ### Environment: Planka version: v2.0.0-rc.3 Deployment: Docker Compose Container timezone: (properly set and verified)TZ=Asia/Shanghai Local time: CST (UTC+8) Actual time difference: 16 hours (not the expected 8 hours for UTC/CST difference) ### Desired behavior ### **Issue** Details: ### Container timezone is correctly configured: docker exec -it <container> env | grep TZ # Output: TZ=Asia/Shanghai docker exec -it <container> date # Output: Fri Jul 25 10:25:01 CST 2025 Webhook timestamps show 16-hour difference: Local time: 10:25 AM CST Webhook timestamp: Shows time that is 16 hours behind local time This is not the standard 8-hour UTC/CST difference Root cause identified: The issue appears to be in line 83 where is hardcoded .env.sample:83 , overriding container-level timezone configuration.server/.env.sampleTZ=UTC ### **Network location tested:** Initially tested with server IP in Seattle, Washington Changed to local network IP - 16-hour difference persists Confirms the issue is not related to network/geographic location Expected Behavior: Webhook timestamps should either: ### Respect the container's setting, orTZ=Asia/Shanghai Show standard UTC time (8 hours behind CST, not 16 hours) Actual Behavior: Webhook timestamps consistently show a 16-hour time difference from local CST time, regardless of: ### Steps to reproduce **Container timezone configuration** Network location/IP address System time synchronization Proposed Solutions: Allow the application to respect the container's environment variable instead of hardcoded UTCTZ **Add a separate configuration optionWEBHOOK_TIMEZONE** Fix the underlying issue causing the abnormal 16-hour offset Additional Context: The 16-hour difference is unusual and suggests there may be a double timezone conversion or other calculation error in the webhook timestamp generation process. This significantly impacts webhook integrations that depend on accurate timestamps. Allow the application to respect the container's environment variable instead of hardcoded UTCTZ **Add a separate configuration optionWEBHOOK_TIMEZONE** Fix the underlying issue causing the abnormal 16-hour offset ### Other information _No response_

OVERLORD closed this issue

2026-02-04 21:15:52 +03:00

OVERLORD commented

2026-02-04 21:16:00 +03:00

@meltyshev commented on GitHub (Jul 25, 2025):

Hi!

I believe the issue is caused by setting TZ=Asia/Shanghai for the container. In PLANKA, we store all dates in UTC and then convert them on the client side to the user's local timezone - this approach ensures proper support for users in different time zones.

However, the PostgreSQL driver uses the TZ environment variable to automatically convert timestamps to the specified timezone when saving - which is a bit unexpected, especially since we've explicitly defined all datetime fields as WITHOUT TIME ZONE.

To make this work correctly, we set TZ=UTC in the .env file. But if a user overrides this variable (as you did), the driver applies the wrong timezone when saving - in your case, it adds 8 hours when saving the data. Then, when fetching the data, since the fields are stored as WITHOUT TIME ZONE, the driver assumes they're in UTC and applies another +8 hours during conversion to your local TZ. That's why you see a total 16-hour offset.

To fix this simply remove the TZ=Asia/Shanghai setting from the container. This will ensure all dates are stored and interpreted as UTC.

From our side, I'll look into improving this behavior to avoid relying on such hidden logic - perhaps by tweaking the driver settings and removing the need for the TZ variable entirely.

@meltyshev commented on GitHub (Jul 25, 2025): Hi! I believe the issue is caused by setting `TZ=Asia/Shanghai` for the container. In PLANKA, we store all dates in UTC and then convert them on the client side to the user's local timezone - this approach ensures proper support for users in different time zones. However, the PostgreSQL driver uses the `TZ` environment variable to automatically convert timestamps to the specified timezone when saving - which is a bit unexpected, especially since we've explicitly defined all datetime fields as `WITHOUT TIME ZONE`. To make this work correctly, we set `TZ=UTC` in the `.env` file. But if a user overrides this variable (as you did), the driver applies the wrong timezone when saving - in your case, it adds 8 hours when saving the data. Then, when fetching the data, since the fields are stored as `WITHOUT TIME ZONE`, the driver assumes they're in UTC and applies another +8 hours during conversion to your local `TZ`. That's why you see a total 16-hour offset. To fix this simply remove the `TZ=Asia/Shanghai` setting from the container. This will ensure all dates are stored and interpreted as UTC. From our side, I'll look into improving this behavior to avoid relying on such hidden logic - perhaps by tweaking the driver settings and removing the need for the `TZ` variable entirely.

OVERLORD commented

2026-02-04 21:16:12 +03:00

@meltyshev commented on GitHub (Jul 25, 2025):

Just a quick update: we've added proper time parsing to the adapter, so it no longer relies on the TZ environment variable. This fix will be included in the next release.

In the meantime, you can simply remove TZ=Asia/Shanghai from the container to avoid the issue.

Also, in my previous comment, I mentioned that the database was saving data with the wrong timezone. After rechecking, the data is actually saved correctly. The problem occurs when the pg adapter parses the date back from a WITHOUT TIME ZONE column - it applies the configured TZ twice, which causes the time offset.

@meltyshev commented on GitHub (Jul 25, 2025): Just a quick update: we've added proper time parsing to the adapter, so it no longer relies on the `TZ` environment variable. This fix will be included in the next release. In the meantime, you can simply remove `TZ=Asia/Shanghai` from the container to avoid the issue. Also, in my previous comment, I mentioned that the database was saving data with the wrong timezone. After rechecking, the data is actually saved correctly. The problem occurs when the `pg` adapter parses the date back from a `WITHOUT TIME ZONE` column - it applies the configured `TZ` twice, which causes the time offset.

OVERLORD commented

2026-02-04 21:16:13 +03:00

@brucexo commented on GitHub (Jul 28, 2025):

As you mentioned, after removing the settings from the container as suggested, the time has indeed reverted to UTC.

Many thanks for your support!

Hope this helps others who encounter the same issue. Appreciate all your efforts!

@brucexo commented on GitHub (Jul 28, 2025): As you mentioned, after removing the settings from the container as suggested, the time has indeed reverted to UTC. Many thanks for your support! Hope this helps others who encounter the same issue. Appreciate all your efforts!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/planka#764