This is not yet a proposal, but more a list of known behaviour that timezones exhibit, and which will probably have to be modeled in one way or another to be able to make a proposed Elixir time zone support system useful:
- In essence, timezones are an offset from a given ‘base’ time. Usually we talk about these offsets relative to UTC time itself (but this of course only makes sense w.r.t the ISO8601 calendar)
- However, how far timezones are offset might change, meaning that local wall clock time might have times that ‘occur twice’, as well as sections of time that ‘do not appear at all’.
- When timezones change their offset also varies: The most common form of this is known as daylight savings time, (which some locations start or end at midnight, and others at two in the morning, for instance; also, europe and the US perform their DST shift a couple of weeks apart). However, there are other forms, as well as political reforms that alter the offset permanently for a given geographical region.
- Above rules mean that when someone creates a datastructure representing a future datetime, they might:
- keep it as-is, which will mean it is influenced by (political) changes in timezone rules between ‘now’ and the specified datetime.
- transform it to an absolute (i.e. UTC) datetime, which means it will not be influenced by these.
Whichever one of these is more reasonable depends on the context at hand, so this choice needs to be open to the user (the application programmer).
please tell if you see an oversight, mistake or ommission in here and I’ll update the list.
