Another great example of how the core team actively promotes community involvement

…and can I just say, congrats on joining the Elixir Core Team Michał

First and foremost, I’d like to ask: What is the Elixir Core team’s current view on handling leap seconds? Would leap second handling be expected to be part of this new system, would it be ‘opt in’ based on what timezone functionality would be created, or would it explicitly not be something we’d want to consider at this time?

And, related: What functionality should be kept in Calendar and what should be part of timezones? Would timezones play a role when using a calendar other than Calendar.ISO?

And also from me, congrats on joining the Core team, Michał!

I would expect timezone support in calendars other than Calendar.ISO. I am nearly completion of a lib supporting other calendars (ISO Week, 445/454/544, various business calendars) that are based upon the Gregorian proleptic calendar but are different. The concept of time, for these calendars, is the same as Calendar.ISO.

I believe those questions are exactly what the proposals should answer. Although it feels like leap seconds is a bit orthogonal to the timezone concerns? In any case it is unclear if it will be up to the calendar to perform the timezone lookup or if it will be handled separately.

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:
  1. keep it as-is, which will mean it is influenced by (political) changes in timezone rules between ‘now’ and the specified datetime.
  2. 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.

Yes, to be more precise about the first two points. Any DateTime has enough information to convert back to UTC. However, we are unable to receive a NaiveDateTime and a timezone and convert it to DateTime, exactly because we lack the timezone information that would tell us if a wall clock occurs once, twice or not at all in that timezone. This is the smallest proposed change I can see being done to the stdlib.

A post was split to a new topic: Elixir and RFCs

Last post before bed-time, I hope I am still awake to make sense:

I currently think we need the following functionality:

First and foremost, to ensure that the timezones can be used with any calendar, they will work on the
Calendar.iso_days type:

@type day_fraction :: {parts_in_day :: non_neg_integer, parts_per_day :: pos_integer}
@type iso_days :: {days :: integer, day_fraction}

1. Given the current iso_days in the ‘zero’ time (the timezoneless, non-offset time; for ISO8601 this would be UTC), return the day_fraction this timezone is offset from the ‘zero’ time.
2. Given an iso_days in the current timezone, return a list of zero, one or two (is more possible?) day_fraction elements that are offsets from this current timezone iso_days to create possible iso_days in the ‘zero’ time.

Besides these two pieces of core functionality, we might want to standardize some metadata-fields that timezone-implementations should specify, like:

• name
• geographical region
• date range during which this timezone is known to be valid (TZdata, for instance, only keeps current time zone info and therefore might use wrong results for historical dates; we might want to generate warnings when a timezone is attempted to be used outside of its range.)

Exactly from where these calls should be initiated, what modules are in control of the flow, and how it should be wrapped is, I presume, part of the concrete implementation details that are to be considered later.

But from user-land, I think these might be exposed like following
(Here goes the initial attempt at naming things; be gentle ):

DateTime.change_timezone(date_time :: DateTime.t, timezone_name :: String.t) :: {:ok, DateTime.t} | {:error, error}

(This call at least fails if specified string does not identify any known timezone. Are there other potential sources of failure?)

NaiveDateTime.suitable_datetimes_for_timezone(naive_date_time :: NaiveDateTime.t, timezone_name :: String.t) :: {:ok, [DateTime.t]} | {:error, error}

(This call at least fails if specified string does not identify any known timezone. If the timezone is found but the NaiveDateTime does not indicate any valid time, the result list will be empty. Are there other potential edge cases?)

That’s all for now, more tomorrow. I look forward to your critiques!

4 posts were split to a new topic: Should Calendar types and timezones be part of Elixir standard library?