You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Display the time which comes from user input whenever it needs to to be done.
Which has to be exactly same time as user input. In other words, the timezone shouldn't be changed by any interfaces like JS Date API.
Comparing a datetime with the others, ordering by them and whatnot. So basically it's not only about storing and displaying but there's some programatic logics.
Just align solutions
1. When users input a date time info
Users are supposed to know exact location time as in timezone. Program won't try to fetch timezone offset/tz corresponding to the location users input on a browser.
with time zone
If users add offset to timestamp, the datetime with time zone would be inserted.
If not, id'd be the default offset as in UTC, if we don't specify particular timezone as DB tz.
without time zone
Just insert datetime without timezone.
Concern about using without time zone
If we use datetime related function like NOW() or CURRENT_TIMESTAMP, Postgres uses UTC as its timezone by default not concerning about timezone.
Our API provides a feature that orders some data such as activity info by datetime. If ordering by those datetime without time zone, it might be wrong chronological order.
e.g) 2023-12-28T19:10:17.369+08:00 should be before 2023-12-28T18:10:17.369+00:00, but if we focused on only datetime without offset, former one would be seemed as if it's ahead of the latter one. But for sure it's wrong.
3. When fetching data from Postgres through GraphQL API
the data is selected without any data type conversion by supabase, and sent as string type by JSON, since we specified with graphql-codegen
Extract datetime data itself without timezone, cuz we're not gonna show timezone offset, and completely rely on datetime info.
Concern about using without time zone
It's same reason as the number 3, there're some internal logical that orders by and comparing datetime with different location/timezone.
The text was updated successfully, but these errors were encountered:
What we wanna do.
Just align solutions
1. When users input a date time info
Program won't try to fetch timezone offset/tz corresponding to the location users input on a browser.
2. When storing a date time info in Postgres
https://www.postgresql.org/docs/current/datatype-datetime.html
If users add offset to timestamp, the datetime with time zone would be inserted.
If not, id'd be the default offset as in UTC, if we don't specify particular timezone as DB tz.
Just insert datetime without timezone.
Concern about using without time zone
NOW()
orCURRENT_TIMESTAMP
, Postgres uses UTC as its timezone by default not concerning about timezone.e.g)
2023-12-28T19:10:17.369+08:00
should be before2023-12-28T18:10:17.369+00:00
, but if we focused on only datetime without offset, former one would be seemed as if it's ahead of the latter one. But for sure it's wrong.3. When fetching data from Postgres through GraphQL API
Concern about using without time zone
It's same reason as the number 3, there're some internal logical that orders by and comparing datetime with different location/timezone.
The text was updated successfully, but these errors were encountered: