Ask HN: How to handle date, time and timezones for an MVP | Hacker News Reader

Ask HN: How to handle date, time and timezones for an MVP

3 pointsrelaunched7 comments

I'm building an mvp that has core functionality that involves setting date and times for future reminders. I have become completely overwhelmed by what I've read online. One can't just use UTC time, nor can they just track timezones, because of daylight savings. There are tools like pytz, which is just one more tool I have to learn that'll delay launching.

Given I can limit my scope for an MVP, what do you all think is a reasonable approach to handling date and time, for scheduling purposes, for an mvp.

View on HN

It seems you're using python. The standard lib's date and datetime classes are... not great.

A purpose-made library like Delorean [1] or Pendulum [2] will help with handling dates, datetimes, and timezones greatly, despite being another tool to learn. Even Arrow [3], which is popular because of its Moment.js-inspired API, is better than using the builtins, despite muddying a few concepts and making some design choices that I (or the Pendulum author [4]) don't agree with.

In the Java world, Java 8's builtin Datetime API and its predecessor Joda-Time are quite possibly the most thoroughly thought-out, expertly designed datetime libraries that exist today. In my opinion, none of the python libraries quite measure up, but Delorean and Pendulum are pretty solid.

[1] http://delorean.readthedocs.io/en/latest/quickstart.html [2] https://pendulum.eustace.io/ [3] http://crsmithdev.com/arrow/ [4] https://pendulum.eustace.io/faq/#why-not-arrow

Make an API call to Google? ][1] https://developers.google.com/maps/documentation/timezone/st...

An API call is going to be easier to implement than learning a new library.

[1]: Alternatives here: https://stackoverflow.com/questions/16086962/how-to-get-a-ti...

This particular solution requires Lat/Long and I'm not sure that makes a ton of sense for my particular mvp.

If it ever does make sense, I'll be sure to check this out. It's a very convenient API.

A couple of alternatives I considered before suggesting an API.

1. Just use UTC and that it's a feature for the next vesion. It might be a way to start a conversation with early users.

2. Make a system call to the users operating system to determine future dates.

3. Make a system call to the server operating system to determine future dates.

Finally, time zones are hard. How hard? Really hard. By really hard I mean that Apple screwed up on it a few years ago: http://wccftech.com/iphone-daylight-saving-time-bug-how-to-m...

People got over it. Good luck.

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

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.

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.

Reply on news.ycombinator.com