fix: accomodate input timezone while create user without on-boarding and default timezone #18288
Conversation
|
@vijayraghav-io is attempting to deploy a commit to the cal Team on Vercel. A member of the Team first needs to authorize it. |
dosubot
bot
added
the
bookings
Graphite Automations"Add consumer team as reviewer" took an action on this PR • (12/20/24)1 reviewer was added to this PR based on Keith Williams's automation. "Add community label" took an action on this PR • (12/20/24)1 label was added to this PR based on Keith Williams's automation. "Add ready-for-e2e label" took an action on this PR • (12/21/24)1 label was added to this PR based on Keith Williams's automation. |
vijayraghav-io
changed the title
| @@ -683,7 +683,7 @@ model Schedule { | |||
| eventType EventType[] | |||
| instantMeetingEvents EventType[] @relation("InstantMeetingSchedule") | |||
| name String | |||
| timeZone String? | |||
| timeZone String? @default("Europe/London") | |||
There was a problem hiding this comment.
Why are we having "Europe/London" as default timeZone 🤔
There was a problem hiding this comment.
"Europe/London" timezone aligns with UTC or has UTC +0, probably that's why its chosen as default timezone even for users
There was a problem hiding this comment.
Can we directly use UTC timeZone, I think that would be better 🤔 .
There was a problem hiding this comment.
to be in sync with default value for timezone in other tables - User, Team and other places in code, i think it's better to go with Europe/London.
There was a problem hiding this comment.
@emrysal any thoughts in here? Are we comfortable setting this default at DB level?
There was a problem hiding this comment.
I don't see why not, but I don't really adore the idea of default schedules as a whole.
E2E results are ready! |
|
@Praashh , Reminding for merge 🙏 |
|
tagging @anikdhabal for this 🙏 |
I remember checking this scenario - for existing records, if 'timezone' column already has a different value, this migration won't update that row with this new default value. |
|
I think for this one we'd strongly prefer defaulting in application code, as if we default on the DB to Europe/London we have no way of knowing a schedule is a default schedule without a tz specified or the actual timezone of the user, as specified by the user themselves. That's a big reason for keeping it nullable. |
|
Closing after internal consensus on the above, thanks for the contribution though @vijayraghav-io |
🙏 |
What does this PR do?
Mandatory Tasks (DO NOT REMOVE)