
Ask HN: How to handle date, time and timezones for an MVP - relaunched
I&#x27;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&#x27;ve read online. One can&#x27;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&#x27;ll delay launching.<p>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.
======
niftich
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](http://delorean.readthedocs.io/en/latest/quickstart.html)
[2] [https://pendulum.eustace.io/](https://pendulum.eustace.io/) [3]
[http://crsmithdev.com/arrow/](http://crsmithdev.com/arrow/) [4]
[https://pendulum.eustace.io/faq/#why-not-
arrow](https://pendulum.eustace.io/faq/#why-not-arrow)

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

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...](https://stackoverflow.com/questions/16086962/how-to-get-a-time-
zone-from-a-location-using-latitude-and-longitude-coordinates)

~~~
relaunched
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.

~~~
brudgers
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...](http://wccftech.com/iphone-daylight-
saving-time-bug-how-to-manually-set/)

People got over it. Good luck.

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

