Just to throw a nuance into this (because, you know… time zones), when you do this you’ll probably run into the situation of having people enter times that don’t exist because of daylight savings, or times that are ambiguous because they occur twice. Kelecto’s approach seems alright, but if you are planning on doing something like this you may need to consider those edge cases, and how you acquire the offset.
I have worked on some scheduling-heavy applications and it’s been impressive how inevitable it is to run into those sorts of situations. Lay people will never appreciate how complicated, yet deceptively simple representing and working with time is.
Blog poster here. Yes, ambiguous/non-existing datetimes are things that should be considered. I am glad that I’m not the only one that realize that these can be real issues!
Fortunately I have thought of that too. If you try to create a DateTime that does not exist you get an error. If you try to create a DateTime that is ambiguous, the response is tagged with :ambiguous and you get a struct with the two possibilities. You can then choose what to do - ask the user which one he/she wants or maybe you want to just choose one of them based on some kind of algorithm or default.
Specifics are in the Kalends docs: http://hexdocs.pm/kalends/Kalends.DateTime.html#from_erl/3
Kalends is the main datetime library that I made. Kalecto is an adapter for Kalends for saving datetimes, dates and times to a database with the Ecto library.
Do flights, with their “all times are in local wall time” approach, ever run into these issues?
I certainly run into this problem entering flights into my calendar. The “wherever I am” time zone has very little support in most software.