

The need for timezone awareness - laut
http://www.creativedeletion.com/2015/05/10/the-need-timezones.html

======
emptybits
Trivia questions, easily answered by programmers who appreciate the subtleties
of time math:

1\. If someone leaves Vancouver at 1 am and arrives in Seattle at 4 am on the
same day, and you know the distance they travelled is 240 km, what was their
average rate of speed? (Correct answer: 120 km/h, 80 km/h, or 60 km/h,
depending on what day it is. UTC storage helps here.)

2\. If it's noon in Vancouver, what time is it in London, England? (Correct
answer: 7 pm, 8 pm, or 9 pm, depending on what day it is. Knowledge of
regional DST schedule differences helps here.)

It's my experience that when the programmers get date math _correct_ , they
may still find themselves fielding "bug" reports from enterprise customers who
_should_ understand the concept but don't (particularly if their business is
billing or rate calculation -- think of short term billing for hourly parking
or CPU hours as an example).

~~~
apaprocki
3\. How many simultaneous "days" are active at any given time on Earth? (3;
11pm Wednesday on Baker Island is 11am Thursday in London and 1am Friday in
Kiribati)

~~~
paublyrne
Of course that's not at 'any' given time. That is only between 10am and
11.59am GMT each day.

------
firegrind
I watch Tom Scott's "The Problem WIth Time And Time Zones" from time to time
just as a reminder

[https://www.youtube.com/watch?v=-5wpm-
gesOY](https://www.youtube.com/watch?v=-5wpm-gesOY)

~~~
laut
It is a good video. The good thing about using a library like Kalends is that
it takes into account everything he mentions about different timezones into
account. Just tell it the time, date, and timezone name.

Just be careful about generalizing too much and assuming things such as: "this
time will exist again tomorrow". Or "next month also has a 31st day". Or "DST
is always a 3600 second difference from standard time".

Here is another article I wrote which also talks about some pitfalls of time
and timezones: [http://www.creativedeletion.com/2015/01/28/falsehoods-
progra...](http://www.creativedeletion.com/2015/01/28/falsehoods-programmers-
date-time-zones.html)

------
loudmax
In my experience, the simplest way to program with times and dates is nearly
always to convert to Unix epoch as early as you can in the process. Do all
processing in Epoch, then convert back to something readable by humans at the
last possible moment. This approach won't work in all circumstances, but it
should be the standard approach unless there's a compelling reason not to.

~~~
laut
Hi, I'm the author of the blog post and the library used in the examples.

For many operations the Kalends library actually converts to UTC (and UTC is
almost the same as epoch). For instance to calculate the amount of seconds
between two datetimes.

Your advice might work in a lot of cases, but if you have a good datetime
library you should not need to IMO. But I am sorry to say that I do not think
most datetime libraries are very good when it comes to timezones.

You don't have to manually say: oh this datetime is not UTC, I better convert
it as soon as possible. If you need to save a future datatime which is not
UTC, it is actually error prone to convert to UTC.

What Kalends does instead is to have a struct with an unambiguous, validated
datetime and the timezone along with it.

That way, if for instance you are dealing with a datetime entered by a user,
you have the actual datetime entered, but you still have all information you
need to convert to UTC.

~~~
jasode
_> If you need to save a future datatime which is not UTC, [...] a struct with
an unambiguous, validated datetime and the timezone along with it._

It's _less_ ambiguous but it's not 100% unambiguous because _future_ policies
of Daylight Saving Time and Time Zone / Time offset boundaries can be changed
by governments.

Even if the struct had extra fields for flags such as "obey future DST
changes" or "ignore present TZ if different from historic TZ at time of data
entry", it's still ambiguous if geographic coordinates are not embedded within
the struct. Then again, there's probably some more edge cases even with
latitude/longitude coordinates. (E.g. should the future time be interpreted at
lat/long of where he _data-entered_ the datetime, or the lat/long of where he
later _experiences_ the datetime?!)

Dates specifying future events are very tricky++. Unless, it's a future date
for something celestial such as a solar eclipse; in such cases, a future date
as UTC is unambiguous.

++Because we all conflate concepts of "socially-constructed future datetime as
shown on a wall clock" and "scientific future datetime". We stuff both
concepts into the same data structures. Nevertheless, we write software that
makes educated guesses about the user intentions for "future dates" and it
works for 99% of the typical use cases. (e.g. "send smartphone notification
for 12:30 lunch with Bob next week.)

~~~
laut
Right, it is unambiguous for the current rules and zone. Usually if the rules
change, you want to do the calculation again. I made a library for persisting
future DateTimes to a database. Whenever a DateTime is loaded from the
database, the calculation is done again. A blog post about it can be found at
[http://www.creativedeletion.com/2015/03/19/persisting_future...](http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html)

If the "borders of the timezones" change, that does not make it unambiguous,
because the struct is defined as belong to a timezone name, not a specific
geographical location.

~~~
curun1r
What I find missing from most, if not all, date/time libraries is a three-arg
timezone conversion function (i.e. one that is pure and doesn't rely on the
current time or locale). Most timezone conversions take a zoned date and time
and convert it to a different timezone. But it matters when/where you're doing
the conversion for the reasons you're discussing. If you also supply a UTC
timestamp indicating when the conversion should take place (note, not a zoned
date and time, since the conversion to the universal timeline can be affected
by DST changes), that conversion can be consistent no matter when/where the
function runs.

I find this approach to be cleaner than saving wall time since it allows you
to keep uniform times on the server and simplify server-side logic that acts
on those times in bulk.

------
oulipian
Try living in a time zone that is a half-hour deviation from standard time
(Newfoundland & Labrador). When I first got an iPod my time zone simply wasn't
supported by the software:
[https://discussions.apple.com/thread/179539](https://discussions.apple.com/thread/179539)

~~~
NKCSS
Try living in Nepal [0] ;)

[0]
[http://www.timeanddate.com/worldclock/nepal/kathmandu](http://www.timeanddate.com/worldclock/nepal/kathmandu)

~~~
ceejayoz
My favorite is Amsterdam Time.

[http://en.wikipedia.org/wiki/UTC%2B00:20](http://en.wikipedia.org/wiki/UTC%2B00:20)

> The exact timezone was GMT +0h 19m 32.13s until March 17, 1937...

Yes, 32.13 seconds.

~~~
rs232
Wow, TIL. Any idea why?

~~~
colefichter
Every town used to have their own local time based on the sun being at zenith
at local noon. For example, a place like Oxford would be a few minutes behind
London.

With the advent of railways, it became necessary to standardize things a bit.
You can imagine the difficulty if each town a train stopped in had its own
timezone!

There's an interesting podcast from BBC that covers this:
[http://www.bbc.co.uk/ahistoryoftheworld/objects/u6Qnc25jQ5OI...](http://www.bbc.co.uk/ahistoryoftheworld/objects/u6Qnc25jQ5OIO-X92mZz6Q)

------
Roritharr
Living in germany I often times have to raise eyebrows at the basic
assumptions american coders often have with regards to encoding, timezone
awareness and other common defaults.

An american friend with french heritage noticed happily after moving to
germany that the accent de gue on his last name was finally printed correctly
on his mail and packages.

~~~
maljx
Lets not get carried away - everyone in Germany misspells my Swedish first
name. (Because I use a spelling that is not used in Germany everyone here
"corrects" my name, even when I enter myself it on websites, etc.)

~~~
rogerbinns
My French friend Stéphane (male) had a lot of trouble in the US. A very large
number of sites and services don't let you enter the accent. Many places that
had any kind of the human in the loop would also "correct" his gender to
female and name to Stephanie.

------
lucb1e
Well that answers the question I've been asking people for years: why do
people keep using PST when everyone in the world understands UTC+/-X but
nobody has a timezone table in their heads? Well, timezones change (using
summertime or not changes the most).

~~~
chimeracoder
> why do people keep using PST

Especially when, for most of the year, even the US west coast doesn't use PST
(they use PDT).

You may think I'm being pedantic, but most naive timezone conversion tools
won't pick up this error for you, if you ask them to convert "1PM in PST to my
local time". I once ended up on a conference call at the right time by myself
because the other party assumed that London time was the same as UTC (it's not
- they were in Daylight Saving Time, so they were an hour ahead).

------
a3n
Time is huge. You cannot get it right in all cases. You can only get it right
for your particular case. If you try to get it right for all cases, you waste
resources on something that mostly doesn't matter, and dwarf your other
resources.

Time is not just calendar apps, or cron. Consider relative dates in historical
studies that span past, present and future.

Study the fuck out of your use case, get it right, don't worry about others'
opinions and don't think that your solution applies generally to most other
use cases.

Also, among the many resources for general and specific solutions to time
problems is "Calendrical Calculations," by Dershowitz and Reingold. I found it
randomly, bought it on a lark, and hope to $DEITY I never haver to care about
time for anything critical.

[http://www.worldcat.org/search?qt=worldcat_org_all&q=calendr...](http://www.worldcat.org/search?qt=worldcat_org_all&q=calendrical+calculations)

~~~
davotoula
$265.90

Bought it on a lark??

~~~
a3n
Really? Wow. I was cruising the shelves of SoftPro books (back when they had
shelves and a physical presence). The sticker on my copy says $32.99.

Well, the link I provided was to a worldwide library catalog, you should be
able to interlibrary loan it to your branch if you're interested.

Or you can get a copy on Abe Books for pretty cheap.

[http://www.abebooks.com/servlet/SearchResults?sts=t&tn=Calen...](http://www.abebooks.com/servlet/SearchResults?sts=t&tn=Calendrical+calculations)

But no, my upper lark limit is considerably lower than $265.90. :)

------
robmcm
I find most people doen't understand the difference between timezone and time
offset.

I reciently had a huge issue trying to explain to people why we couldn't
(easily) show the offset next to the city on a date time input, because we
didn't have a native library to do it. They couldn't grasp that a date in the
future could have a different offset for the same city and that they didn't
all change at the same time.

If anyone is using JS checkout moment.js and also be aware that date objects
in most client side runtimes are in the users timezone by default, and often
doen't let you change the offset.

------
leni536
According to cron's man page on Debian the "fix" that makes cron work on DST
is "Debian specific". What happens on other distributions?

On Debian: [http://debian-handbook.info/browse/stable/sect.task-
scheduli...](http://debian-handbook.info/browse/stable/sect.task-scheduling-
cron-atd.html#idm139883800332112)

~~~
Ded7xSEoPKYNsDd
Fedora uses cronie as crond, which does something similar:
[https://git.fedorahosted.org/cgit/cronie.git/tree/man/cron.8...](https://git.fedorahosted.org/cgit/cronie.git/tree/man/cron.8#n112)

------
protomyth
I'm pretty sure we had a big discussion on this a couple of months ago, but I
cannot find the link.

Don't forget that for a lot of applications your users don't care about time
zones. "I have a meeting every Monday morning at 10:00AM and some folks from
around the world call in". Its up the the programmer to figure that out for
all involved.

------
azurelogic
This was our topic from our local dev meetup last month. We have a video of it
here:
[https://www.youtube.com/watch?v=ZQAELeiY68E](https://www.youtube.com/watch?v=ZQAELeiY68E).
Interesting discussion of weird time bugs too.

------
lorenzfx
Even when using a library that supports timezones (and DST), handling them is
still a pain, especially if one has to deal with timezone aware and _floating_
datetimes at the same time.

------
Olap84
Its not just your code that needs timezone awareness, users are all shockingly
bad at understanding timezones. Daylight savings in particular needs to die.

~~~
gutnor
The hardest I have noticed is to make them understand that it is not only the
time, but also the date that change.

So when discussing whole timestamp or time - everybody is somewhat aware there
is going to be timezone involved.

Good luck however, if you need to ask the question: "Is the instruction date
(yyyy-mm-dd) in the Counterparty (Sidney), Party (London) or System timezone
(Brussels) ?"

