graphql-engine icon indicating copy to clipboard operation
graphql-engine copied to clipboard

Event triggers created_at time shifted +09:00

Open tatsuhirokasai opened this issue 1 year ago • 4 comments

Version Information

Server Version: v2.40.0

Environment

OSS

What is the current behaviour?

The created_at values displayed on the Processed Events page and Invocation Logs page in the Hasura Console are offset by 9 hours.

What is the expected behaviour?

The values should display the actual time when the events were executed (i.e., the values should reflect the time 9 hours earlier).

How to reproduce the issue?

  1. Create an event that triggers when data is INSERTed into any table.
  2. Perform an INSERT operation on the table.
  3. Check the logs on the Hasura Console's Events page.

Screenshots or Screencast

image

image

Please provide any traces or logs that could help here.

Event payload:

{
    "headers": [
        {
            "name": "Content-Type",
            "value": "application/json"
        },
        {
            "name": "User-Agent",
            "value": "hasura-graphql-engine/v2.40.0"
        }
    ],
    "payload": {
        "created_at": "2024-06-24T14:22:32.128413",
        "delivery_info": {
            "current_retry": 0,
            "max_retries": 0
        },
        "event": {
            "data": {
                "new": {
                          :(snip)

Any possible solutions/workarounds you're aware of?

Execute the following SQL commands:

ALTER TABLE hdb_catalog.event_invocation_logs 
ALTER COLUMN created_at TYPE TIMESTAMPTZ;

ALTER TABLE hdb_catalog.event_log
ALTER COLUMN created_at TYPE TIMESTAMPTZ;

Ref. https://github.com/hasura/graphql-engine/issues/5722

Keywords

event trigger, time zone, TIMESTAMPTZ

tatsuhirokasai avatar Jun 24 '24 05:06 tatsuhirokasai

Hey @tatsuhirokasai, thanks for raising this issue. I'm not able to reproduce this issue on my machine. Can you tell me more about the issue you are facing -

  1. Was the local time when the event was triggered shown correctly on the console i.e. 11:22 PM? If yes, then the +9:00 actually represents that your local time is 9 hours ahead of UTC.
  2. Also give me the time zone of your Graphiql Engine, Postgres server and Browser.
  3. Is your Postgres server migrated from some other timezone?

ALTER TABLE hdb_catalog.event_invocation_logs ALTER COLUMN created_at TYPE TIMESTAMPTZ;

ALTER TABLE hdb_catalog.event_log ALTER COLUMN created_at TYPE TIMESTAMPTZ;

Regarding your suggestion, checkout this comment

Varun-Choudhary avatar Sep 11 '24 11:09 Varun-Choudhary

Hey @Varun-Choudhary , Thank you for checking. Here are the answers to your questions:

  1. Was the local time when the event was triggered shown correctly on the console i.e. 11:22 PM? If yes, then the +9:00 actually represents that your local time is 9 hours ahead of UTC.

The actual event occurred at 2:22:32 PM +9:00, but as illustrated in the figure, it was displayed on the console as 23:22:32 +9:00, which is effectively 11:22 PM +9:00.

  1. Also give me the time zone of your Graphiql Engine, Postgres server and Browser.

For the GraphiQL Engine, I have set the following environment variable: TZ=Asia/Tokyo This time zone is 9 hours ahead of UTC.

For the Postgres server, when I execute the show timezone command, it displays Asia/Tokyo.

I have not specified a time zone for the browser, but the time zone on my Mac is set to Asia/Tokyo.

  1. Is your Postgres server migrated from some other timezone?

No, the Postgres server was newly set up.

tatsuhirokasai avatar Sep 18 '24 01:09 tatsuhirokasai

Thank you @tatsuhirokasai for the detailed info. We can reproduce this issue. We are actively working to fix it asap. As a workaround, you can remove the TZ from the Postgres database and it should work.

Varun-Choudhary avatar Sep 23 '24 06:09 Varun-Choudhary

@Varun-Choudhary Thank you for the prompt response and for actively working on a fix for the issue. I appreciate the workaround suggested, and I will try removing the TZ from the Postgres database as recommended. Looking forward to the permanent fix, and thanks again for your support!

tatsuhirokasai avatar Oct 04 '24 00:10 tatsuhirokasai