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

Design of timezone #20

Closed
Yo-mah-Ya opened this issue Dec 29, 2023 · 1 comment
Closed

Design of timezone #20

Yo-mah-Ya opened this issue Dec 29, 2023 · 1 comment
Assignees

Comments

@Yo-mah-Ya
Copy link
Contributor

Yo-mah-Ya commented Dec 29, 2023

What we wanna do.

  1. 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.

2. When storing a date time info in Postgres

https://www.postgresql.org/docs/current/datatype-datetime.html

  • 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.

@Yo-mah-Ya Yo-mah-Ya self-assigned this Dec 29, 2023
@Yo-mah-Ya Yo-mah-Ya mentioned this issue Jan 6, 2024
4 tasks
@kanatagu kanatagu mentioned this issue Jan 31, 2024
4 tasks
@kanatagu
Copy link
Contributor

Solved the problem with this PR. I will implement Activity form in the same way.
#25

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants