Skip to content
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

Event triggers created_at time shifted +09:00 #10308

Open
tatsuhirokasai opened this issue Jun 24, 2024 · 3 comments
Open

Event triggers created_at time shifted +09:00 #10308

tatsuhirokasai opened this issue Jun 24, 2024 · 3 comments
Labels
c/console Related to console k/bug Something isn't working

Comments

@tatsuhirokasai
Copy link

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.
#5722

Keywords

event trigger, time zone, TIMESTAMPTZ

@tatsuhirokasai tatsuhirokasai added the k/bug Something isn't working label Jun 24, 2024
@manasag manasag added the c/console Related to console label Sep 4, 2024
@Varun-Choudhary
Copy link
Contributor

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

@tatsuhirokasai
Copy link
Author

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.

@Varun-Choudhary
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c/console Related to console k/bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants