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

Customize generated PostgreSQL created_at and updated_at columns to use timestamptz #106

Open
Tracked by #138
55octet opened this issue Oct 18, 2021 · 2 comments
Open
Tracked by #138
Assignees
Labels
breaking change This feature / fix introduces breaking changes s: triage
Milestone

Comments

@55octet
Copy link

55octet commented Oct 18, 2021

When fizz automatically adds the created_at and updated_at columns to a table, it uses the timestamp instead of timestamptz columns. This sort of a issue when you are trying to handle different time zone in the database. It can become problematic when you are using AWS RDS and have clients in different TZs; the PostgreSQL database default to UTC.

I will happily submit a PR to add the functionality to "customize" the timestamp generation, but I want to check with the maintainers to see where and how I should add that customization. Naturally, I was thinking that it could be done in the Table structs (where there are different func to adjust the table name), but that isn't much better than manually added each column in the fizz migrations. Thoughts?

Thank you!

@55octet
Copy link
Author

55octet commented Oct 18, 2021

@sio4 sio4 self-assigned this Sep 7, 2022
@sio4 sio4 added breaking change This feature / fix introduces breaking changes s: triage labels Sep 7, 2022
@sio4 sio4 added this to the v2 milestone Sep 7, 2022
@sio4
Copy link
Member

sio4 commented Sep 7, 2022

I agree. the current behavior could be an issue for global applications, and it is not a best practice even though the behavior was common in the past days. Actually, there were related discussions but we just keep this behavior as is since:

  • The change could break existing applications
  • We need to be consistent on the behavior across all supported databases as much as possible

TZ things will be one of the focus areas for the next release, and I will keep my eyes on this issue.

Thanks!

FYI, related issues:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change This feature / fix introduces breaking changes s: triage
Projects
None yet
Development

No branches or pull requests

2 participants