laut

Do you sell to consumers? Do you sell an average of more than one order each day to different countries?

This is a problem for smaller companies selling to consumers in various European countries every day.

I know companies for which these rules are a big problem.

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

The reason the offset is changed is ambigous datetimes that occur when going off of DST.

Let us say a user enters a datetime in the autumn. It happens to be a few minutes after the clocks are set back an hour. So the time is ambiguous. Which datetime exactly does the user want? The one before or after the clocks are set back? We show him a dialog and he chooses one. To differentiate we use the standard offset which is usally 0 or 3600 seconds.

Great, now we save it to the database as just wall time and timezone name and load it again. How do we know if it is 02:05 before the clocks are set back or 02:05 after the clocks are set back? We don't, unless we saved the UTC offset. But if we save the offset we know exactly which one it is.

But we don't want to use the offset we calculated from the beginning. That would get us the same error as if saving just the UTC time. So we only use the offset if we absolutely have to. This is what Kalecto does when loading a saved datetime from the library: we do the calculation based on the saved "wall time" and the timezone name. If that wall time is ambiguous we use the UTC offset. If there were no changes to the rules for that timezone - no problems.

Now, if we have a combination of the timezone rules changing and the saved datetime being ambiguous, the entered choice is no longer valid. We have to ask the user again or report an error.

I hope this explains it better.

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

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.

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.

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.

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

This Danish startup does something like "airbnb for package delivery" but without a third party company such as UPS: http://trunkbird.com/ People bring stuff in their car if they are driving to another city.

No it is not how it looks it is that the documentation is lacking. The quick start didn't work for me. If it had been a simple page returning HTTP code 200 that just said OK, it would at least be something.

Sure you can make it work if you invest more time in it, but the point is that there are other platforms that have taken care to make it easier.

In general a lot of people seem to think that documentation is one of the biggest issues with Erlang.

I just tried running Chicago Boss. I followed the quick start guide that had a lot of steps and managed to get a 404 error.

With Rails there are less steps: gem install rails && rails new path/to/your/new/application && cd path/to/your/new/application && rails server and you just point your browser to http://localhost:3000 and get a nice welcome page for your new skeleton app.

Chicago Boss could be improved in that respect.

When I wrote "not as easy" I did not mean simply difficult. It just takes a bit more work with Erlang.

As for Erlang string handling: [175,95,40,12484,41,95,47,175] ;)

The good thing is that Erlang and Elixir can benefit from each other. For instance https://hex.pm which is made in Elixir, but can also be used for Erlang projects.

yes

Javascript has functional features too. A lot of Elixir developers come from platforms such as Python, Ruby, node.js

Author here. I wrote some reasons to why I think it is likely that it will be. It is not a sure thing of course.

You cannot know for sure how many leap seconds there will be in for instance the next 5 years. So you cannot know for sure exactly how many seconds there will elapse from now until for instance July 1st 2020 midnight UTC.

If I enter "10:00 in Chile" in a calendar app I expect it to stay "10:00 in Chile". And not magically change to "11:00 in Chile". That is what the example was.

The important part is local time plus timezone.

The offset is there only for the very rare case that you save a time that you know is ambiguous when you save it. And when DST rules don't change. Usually it happens when you change from DST to non-DST in the autumn and a certain hour happens twice.

In the example, the offset will not be used. Only local time plus time zone.

edit: I have updated the article to explain this part.

That is outside of the scope of the article. In this case you have to ask yourself. Do you want to save an appointment for 18:30 in Chile? Or for the Superbowl? You have to choose one.

If you really want to be sure tell your friends to use the timezone of the event. Maybe say "let's meet at 19:00 New York time" if the game starts at 20:00 in New York and you want to meet an hour before.

The article is about saving datetimes. Usually calendars use datetime too.

If you need to count down X hours you are not looking to save a datetime. Maybe use an egg timer or the countdown feature of a smartphone.

TAI would be better than UTC for the next Lunar eclipse in case you want to be exact to the second ;)

But yes, if you schedule the meeting in UTC, use UTC. The point is not to convert from non-UTC to UTC.

I don't think you understood the described problem with storing the time in UTC. In the example in the article it is assumed and your software gets the timezone update. But because the meeting is stored in UTC, it displays the wrong time.

The reason it works for you is because you schedule in UTC. That's great, but for people that don't schedule meetings in UTC, you are vulnerable to the problem described if you just save the time in UTC.

Do you schedule meetings with your dentist in UTC too? I'd wager that most meetings are not scheduled in UTC.

In the example in the blog post the meeting takes place in Chile, so Berlin time is irrelevant.

But let's say you are arranging a conference call between someone in Chile and someone in Berlin. When you arrange the meeting you have to define when the meeting takes place. So you have to choose a time zone along with a time for when the meeting starts. You could choose UTC, Berlin or Santiago. But you have to choose one.

Good question!

It is optional to store the UTC offset. The reason to store the UTC offset is to avoid ambiguity there might be when the timezone rules do not change.

If the timezone rules don't change and you happen to be storing a datetime that is during changing from DST to non-DST, you specify which specific time you are talking about. In autumn, clocks could be set back from 3:00 to 2:00. 2:30 happens twice. When you schedule the time you can ask the user "2:30 summer time or 2:30 winter time"?

So you only use the offset for anything in rare case there is an ambiguity (usually because of going off of DST), otherwise you just ignore it. In most cases even if the rules change like in the Chile example you would ignore it as well and use the offset provided by the timezone database.

Let's say the meeting is supposed to take place at 15:00 "wall time" in Sydney on March 30th. Someone changes the DST rules. The meeting still takes place at the specified time. Remember we specify the time at Australia. So far so good.

Usually the time from a new update is released at least a week before the change takes place. So your software might alert you about the time on the same day or the day before of the meeting. Or even half an hour before. Do the calculations at that time of the alert with the newest timezone data. And if the software is up to date with timezone database changes, users in other time zones will be alerted about the correct time. The calculation will be made before the meeting from 15:00 Sydney to whatever other time zone someone might be in.

Author here. When the timezone rules change, the software updates its timezone database. This is how it should be. You don't have to change the software, the software should be able to handle the changes to the timezone database.

The updates are available here: http://www.iana.org/time-zones So far there has been two new releases of the database in 2015. Last year there were about 10 changes.

Yes. But in this case the timeline is something like this:

1) You arrange a meeting 2) Then, after you have arranged the meeting, politicians/bureaucrats decide to change the time zone rules 3) Your meeting takes place

At 1) the rules are different from at 2). At 1) you cannot see into the future and anticipate how the rules will be at 2), because you don't have a time machine. So you have to be ready for it by implementing in a way that is resistant to timezone rule changes. For instance like the described solution.

Author here. Yes, the error was to save any other time than the local time where the meeting is supposed to take place.

The point of the post was to demonstrate that when storing future events that is supposed to happen in a certain timezone, save the local time (along with timezone) instead of converting to UTC.

This post describes examples of ambiguity and non-existing times: http://www.creativedeletion.com/2015/01/28/falsehoods-progra...

Note non-existing times mostly happen when you go from winter time to summer time. You set the clock ahead an hour at let's say 2:00 in the morning. So you go directly from 2:00 to 3:00. 2:30 does not exist.

So let's say that you plan a meeting at 2:30 in the morning in a country that does not use DST. Then they decide to use DST and set the clocks forward one hour at 2:00. Your meeting was supposed to take place at 2:30 local time, but that time no longer exists! As I see it, the right thing to do is to alert the user of the problem.

The problem is that the meeting time is defined in terms of the "wall time" in Chile.

So if you store the time in terms of UTC, then you are going to have problems when the relation between UTC and the Santiago/Chile timezone changes.

The computer in the example has the time wrong because it stored the time in UTC.

Go is from 2009. Ruby is from 1995. Although it took about 10 years for Ruby to really start to be popular in the English speaking world.