3 ms·

Store in whatever format your scheduler uses, which is probably UTC or crontab format, no? For an MVP it doesn't matter as long as it works. After you outgrow

by welder 10y ago

Store in whatever format your scheduler uses, which is probably UTC or crontab format, no? For an MVP it doesn't matter as long as it works. After you outgrow your MVP the standard way to store datetimes for scheduling and rendering is: 1. Always store datetimes as UTC. You keep seeing this because it's correct. Yes you can store in UTC and display or schedule in another timezone. Scheduling is easy when everything is in UTC. 2. Keep an Olson timezone string (America/Los_Angeles) for each user server-side. Create a template filter for django/flask to render your datetimes for the given user's timezone. This is trivial for pytz and the built-in Python datetime library. 3. Use Moment.js and Moment-Timezone to render utc datetimes in the user's current browser timezone. You can choose to use the server-side timezone or the browser's timezone when rendering. I personally always use the server-side timezone. Always do 1 and 2. 3 is optional if you prefer rendering datetimes server-side. Edit: Why the downvotes? Anyone care to comment on why you think this way is wrong? It's been working great for https://wakatime.com https://wakatime.com

oftenwrong 10y ago
Well, I didn't downvote, but I will say this about #1: The trouble with always storing datetimes in UTC is that the UTC offset observed in a given location is not predictable for future dates. -- Concrete example: I am in Massachusetts. Currently, Massachusetts observes two UTC offsets during the year. Eastern Daylight Time (EDT), which is UTC-4, and Eastern Standard Time (EST), which is UTC-5. EDT is our time zone for Daylight Savings Time (DST). Currently, there is some discussion about how much this arrangement sucks due to the early sunsets we experience being on the edge of the time zone. Some (including myself) are pushing for Massachusetts to switch to Atlantic Standard Time (AST), which would keep us at UTC-4 all year. So, let's say I want to schedule a meeting for November 18th, 2019 at 12pm in Cambridge, Massachusetts. I want a reminder 15 minutes before the meeting so that I do not miss it. I put that into your scheduling system, and you store it as the UTC datetime 2019-11-18T17:00:00Z because Massachusetts' current time zone observance rules say it will be in UTC-5 on November 18th, 2019. Now, let's say I get my wish, and Massachusetts switches to AST year-round some time between now and my scheduled meeting. When 2019-11-18 comes around, Massachusetts will not be in UTC-5, as predicted, but in UTC-4! I will receive my meeting reminder at 12:45pm local time, a full hour after I wanted to receive it, and I will have missed my meeting. -- There are different ways around this, such as storing the datetime with the predicted UTC offset, or storing a localtime (time-zone-less datetime) and the location of the event. The key point is that you need to be able to account for calendar changes. Of course, there is no fool-proof way to store a future date. For all we know, 12pm November 18th, 2019 may not ever occur in Massachusetts because some decision may cause the commonwealth to switch forward past that time entirely. A calendar change could cause even more bizarre situations. In the British Empire, the day after September 2nd, 1752 was September 14th, 1752 due to the adoption of the Gregorian Calendar. Realistically, you are not going to be able to account for that sort of calendar change, but time zone observances change all the time.
- welder 10y ago
  If the meeting time is also stored in UTC then both meeting time and reminder time get an updated display offset and are still the same time apart from each other. Yes, the meeting time would be automatically changed from 4pm to 5pm in your timezone, but would have no change for people in other timezones. I would argue this is the expected behavior, and your app should notify users when timezones change which affect their meeting times.

by welder 10y ago

oftenwrong 10y ago

Well, I didn't downvote, but I will say this about #1: The trouble with always storing datetimes in UTC is that the UTC offset observed in a given location is not predictable for future dates. -- Concrete example: I am in Massachusetts. Currently, Massachusetts observes two UTC offsets during the year. Eastern Daylight Time (EDT), which is UTC-4, and Eastern Standard Time (EST), which is UTC-5. EDT is our time zone for Daylight Savings Time (DST). Currently, there is some discussion about how much this arrangement sucks due to the early sunsets we experience being on the edge of the time zone. Some (including myself) are pushing for Massachusetts to switch to Atlantic Standard Time (AST), which would keep us at UTC-4 all year. So, let's say I want to schedule a meeting for November 18th, 2019 at 12pm in Cambridge, Massachusetts. I want a reminder 15 minutes before the meeting so that I do not miss it. I put that into your scheduling system, and you store it as the UTC datetime 2019-11-18T17:00:00Z because Massachusetts' current time zone observance rules say it will be in UTC-5 on November 18th, 2019. Now, let's say I get my wish, and Massachusetts switches to AST year-round some time between now and my scheduled meeting. When 2019-11-18 comes around, Massachusetts will not be in UTC-5, as predicted, but in UTC-4! I will receive my meeting reminder at 12:45pm local time, a full hour after I wanted to receive it, and I will have missed my meeting. -- There are different ways around this, such as storing the datetime with the predicted UTC offset, or storing a localtime (time-zone-less datetime) and the location of the event. The key point is that you need to be able to account for calendar changes. Of course, there is no fool-proof way to store a future date. For all we know, 12pm November 18th, 2019 may not ever occur in Massachusetts because some decision may cause the commonwealth to switch forward past that time entirely. A calendar change could cause even more bizarre situations. In the British Empire, the day after September 2nd, 1752 was September 14th, 1752 due to the adoption of the Gregorian Calendar. Realistically, you are not going to be able to account for that sort of calendar change, but time zone observances change all the time.

welder 10y ago
If the meeting time is also stored in UTC then both meeting time and reminder time get an updated display offset and are still the same time apart from each other. Yes, the meeting time would be automatically changed from 4pm to 5pm in your timezone, but would have no change for people in other timezones. I would argue this is the expected behavior, and your app should notify users when timezones change which affect their meeting times.