The need for timezone awareness

http://www.creativedeletion.com/2015/05/10/the-need-timezones.html

by laut • 11 years ago

52 60 11 years ago

Roritharr2• 11 years ago

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• 11 years ago

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

Roritharr2• 11 years ago

I'm not saying we're beyond error, but atleast the input field didn't force you to change the letter or throw an error otherwise. ;)

rogerbinns• 11 years ago

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.

kristiandupont• 11 years ago

Actually I (as a Dane) feel that we are all fortunate because the US is in multiple timezones. Had one of the small single-timezone countries headed the IT revolution, we would surely have much greater problems, similar to the way ascii still lives on in systems where it clearly shouldn't.

thecodemonkey• 11 years ago

As a Dane now living in the US.

All apps I'm building now has a US-audience which means that they have to be timezone aware per default as opposed to apps with a danish audience where I didn't have to be concerned about timezones. The truth is, timezones are a pain.

leni5363• 11 years ago

Many of my collages use the unaccented version of their names just to avoid complications. I use my accents whenever it's possible though.

firegrind• 11 years ago

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

laut6• 11 years ago

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

oulipian• 11 years ago

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

NKCSS• 11 years ago

Try living in Nepal [0] ;)

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

ceejayoz• 11 years ago

My favorite is Amsterdam Time.

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.

leavingfourth• 11 years ago

At least windows recognizes you as a time zone.

https://www.timeanddate.com/worldclock/canada/fort-st-john

I have to communicate to my peers that we live in Arizona because Windows doesn't have anything.

abandonliberty• 11 years ago

I imagine timekeeping isn't a primary concern at the moment :(

Olap84• 11 years ago

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

robmcm6• 11 years ago

I think a more considered way to say that is it's a UX challange.

You have to think about what the user want's to enter and what they want to see. It's especially hard if they are doing something like booking a flight, or car hire in another country, how do you know if they are thinking about local time or destination time?

gutnor• 11 years ago

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) ?"

lorenzfx• 11 years ago

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.

loudmax2• 11 years ago

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.

Rapzid2• 11 years ago

I agree on the point of always be converting, but I'll settle with UTC. IMHO if you have a non-utc time one if two things should happen:

A.) Convert it to Utc.

B.) Show it to someone.

Got some 'splain'n to do if I catch non-utc manipulation or comparison going on in my code bases. And heaven help you should you stick a non-utc time into the database.

laut6• 11 years ago

Here is an example where the "convert it to UTC" rule would fail: http://www.creativedeletion.com/2015/03/19/persisting_future...

I will stick non-UTC time into the database and I made a library to do it.

dlubarov2• 11 years ago

Why do you prefer UTC? I feel storing plain unix times is simplest since there's no time zone information at all. And there's no possibility of forgetting a conversion, since (with most languages/libraries) different types are used for plain unix times vs. local times.

robmcm6• 11 years ago

I agree but this is only half the battle.

To use an Epoch you have to convert it into a timezone aware date (as you stated, as late as possible). Now that could be UTC but more likley it will be a timeZone that observes a daylight savings time.

Consider the epoch of 0, 1st of Jan 1970 or what ever it is. Well that's correct in GMT but if you are in NYC what time is it, how about Singapore, Australia, Huston etc...

lmm• 11 years ago

I think it's best to make an explicit, type-level distinction between these things. JodaTime does this: you can have an Instant (which represents a point in time) or a DateTime (a human-readable date/time with a timezone), and if you try to pass one where the other is needed then you get a compile error.

growse• 11 years ago

This works brilliantly until you discover that the Unix epoch is ambiguous around leap seconds. Good luck sorting epoch-stamped events around leap seconds!

laut6• 11 years ago

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.

jasode2• 11 years ago

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

loudmax2• 11 years ago

Thanks for replying. I fully agree that having a good library is essential, so good on you for writing one for Elixir.

ams6110• 11 years ago

Disagree. Use a date/time library and datatypes. Don't use integers, unix timestamps, or any other naive representation of time.

As with cryptography, don't attempt to write your own date/time code. You will get it wrong. Use the datatypes and library functions in your language or database.

azurelogic• 11 years ago

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. Interesting discussion of weird time bugs too.

lucb1e• 11 years ago

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

realusername• 11 years ago

I was also thinking the same thing, I have to Google this kind of things all the time, acronyms like this are absolutely not useful at all to determine the exact time things are going to run.

chimeracoder• 11 years ago

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

protomyth• 11 years ago

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.

robmcm6• 11 years ago

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.

leni5363• 11 years ago

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

Ded7xSEoPKYNsDd• 11 years ago

Fedora uses cronie as crond, which does something similar: https://git.fedorahosted.org/cgit/cronie.git/tree/man/cron.8...

laut6• 11 years ago

You could the server timezone to UTC to avoid those problems.

emptybits• 11 years ago

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• 11 years ago

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• 11 years ago

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

a3n2• 11 years ago

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

davotoula• 11 years ago

$265.90

Bought it on a lark??

mordocai• 11 years ago

$39.59 on amazon for the paperback, new. $116.90 on amazon for the hardcover, new.

a3n2• 11 years ago

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

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

The need for timezone awareness

Related Stories