Cleaner handling of timezones

[avh4]

(Split from #25)

This is mainly a problem because Elm core does not properly support timezones or even give a way to determine the timezone of a Date value.

Specifically, in our app, we need to let the user choose moments in time, but we want the datepicker to show them dates in their user-selected timezone, which sometimes is different from the timezone of the local computer they are using.

Our investigation has led to the following thoughts about how to make datetimepicker more robust w/r to timezone handling:

• datetimepicker should provide its own data types that directly matches what the pickers can choose (instead of giving back a Maybe Date)
  • datepicker should give a record with year, month, day
  • timepicker should give a record with hour, minute
  • datetimepicker should give a record with year, month, day, hour, minute
• datetimepicker can provide convenience functions to turn the above data types into Date values (documented to note that they will convert using the local timezone of the user's web browser)

[abadi199]

I really like the idea of datetimepicker returning its own data types. I know there's some efforts in elm-core to improve the Date API, if you know any insight of that, maybe we can try to match the API there so when the new Date API is released, we can easily swap the data types with the new core Date type. But if it's still too early for that, I'm fine with designing our own data types.

[avh4]

I think nothing will be changing in core w/r to dates in Elm 0.19. I believe Evan thinks that it will be best to have core be a simple as possible w/r to dates and have a separate elm-lang/time package that is smart enough to include timezone info, etc. I think it's far enough out that it's worth making types here for now.

Probably will have a PR for this next week.