That was what i meant when i said getting hands dirty 
alisinabh
OvermindDL1
Heh. One nice side-effect, it clearly tells you what format your Date/DateTime is in. ^.^
2
alisinabh
I like it too, and since Elixir is a newborn language, maybe this change wont get anybody mad because it is really useful and really Elixir like. It is a nice feeling if Elixir handles it in such a way that there will be no calendar that doesn’t fit into its core structure.
I really like your idea. 
2
michalmuskala
From a developers perspective:
We already had a lot of different Date/Time structures. Each library had it’s own - timex had it’s own, calendar had it’s own, ecto had it’s own, different calendar implementations had it’s own… And it was a horrorshow. The usability of those solutions was extremely poor. If you needed to do anything with dates, you found yourself in an endless pipeline of conversions from one format to another. Please, please, please let’s not go back.
1
Qqwy
TypeCheck Core Team
Well spoken.
I think it is important to realize that there are two separate problems that Elixir Core attempts to solve:
- Ensure that different date/time libraries can communicate, by specifying a single underlying data type.
- Ensure that different calendars can be represented and calculated with; that Elixir is not tied to a single calendar.
The first problem was solved by introducing the Date, Time, DateTime and NaiveDateTime structs. Since Timex, Calendar and Ecto all only worked with the ISO 8601 proleptic Gregorian calendar, it was very natural at that time to include struct fields that matched that calendar.
I think the choice of splitting off the NaiveDateTime was a very smart one that follows the explicit nature of the language.
I also want to praise the Elixir Core team that they had the foresight at that time to think about (2.), included a :calendar field in these structs and alter the way the structs are represented by dispatching to the Calendar behaviour. !
This was what has left room open for the work @kip is doing right now: creating a very nice way of converting between different calendars by using the Rata Die as intermediate representation. This will allow:
- Comparing between two possibly different calendars, even if they do not follow the
:year, :month, :day, :hours, :minutes, :secondsfields in the way thatCalendar.ISOdoes. - Obtaining an interval in
{days, fraction_of_day}between two dates in possibly different calendars. - Adding a
{days, fraction_of_day}interval to a date in any calendar. - Enumerating over an interval between two timestamps (in days, and possibly also any other subdivision or superdivision days)
So: I am really happy with the changes that have been introduced in 1.3, and I am also very happy with the new changes that are being worked on! 
0
Qqwy
TypeCheck Core Team
What would be a really nice addition in the future by the way, is to add a %Period{} struct (Or maybe a %Date.Period{}, %TIme.Period{}, %DateTime.Period{} and %NaiveDateTime.Period{}?) whose fields have the same names as those of the normal structs, and that can be used to specify periodical events, such as ‘1 month and 3 days’.
These could then be combined with a starting date(time) to return the times of periodic events in the future. Other than with an exact interval (a {day, fraction_of_day}), this period is added per-field: in above example, first one month is added to the current date, ending up at the same day next month (or possibly the last day of the month if that month has less days). And then three days are added (maybe rolling over to the next month).
This idea is not new; Joda time uses it as well.
And of course, details of how this would work exactly is something to discuss .
0
josevalim
Creator of Elixir
There is absolutely nothing stopping this from happening today. Otherwise it is like saying you cannot implement another key-value data structure because Elixir already has a Map module. If you want key-value genericity, you can define the protocol and you can define new data types. The same for the calendars data structures.
Given the Gregorian Calendar is the international de facto and using it as a base is what makes sense for the huge majority of developers and the huge majority of times, it makes sense to prioritize its representation.
So while it is very interesting to see how far we can take the calendar structures we have today, I have absolutely no problem with saying we won’t support calendars X, Y and Z since the problem can be solved by a third party. In fact, we may even arrive to the conclusion that the :calendar field is unnecessary and any other calendar should be integrated via a protocol. All it takes is someone to define the protocols in a separate library, call it Zoolendar or whatever, which everyone can depend on when building new implementations.
4
OvermindDL1
Eiji
I agree with protocols and separate time representations idea. Also agree with you that Gregorian should be default.
I can create simple demo structure that combines both notes today. I wws already think about it and want to ask too.
0
Lau
Is there a need to add new data formats to represent dates and times? There are a bunch already: Date, NaiveDateTime, DateTime structs in the ISO calendar. Additionally Erlang already has an integer representation of dates. E.g. {2017,1,8} |> :calendar.date_to_gregorian_days and also functions for “gregorian seconds”.
If we want to add a behaviour for alternative calendar modules, could it simply require functions for conversions to and from ISO structs? E.g. %DateTime{calendar: Calendar.ISO}, and the same for Date and NaiveDateTime.
ISO DateTime structs already support leap seconds. Although there are reasons for not always taking leap seconds into account when doing conversions.
You can know about leap seconds up to ~6 months into the future. The Tzdata library provides this information. The Calendar library (calendar on hex) uses the tzdata to make this list native Elixir 1.3+ DateTime structs. Example:
iex> Calendar.TimeZoneData.leap_seconds |> List.last
%DateTime{calendar: Calendar.ISO, day: 31, hour: 23, microsecond: 0,
minute: 59, month: 12, second: 60, std_offset: 0, time_zone: "Etc/UTC",
utc_offset: 0, year: 2016, zone_abbr: "UTC"}
This functionality is also used to validate DateTime structs where the second field has a value of 60.
Calendar.DateTime.from_erl({{2015, 12, 31}, {23, 59, 60}}, "Europe/London") returns an error because there was no leap second at 2015 December 31st.
Calendar.DateTime.from_erl({{2015, 12, 31}, {23, 59, 60}}, "Europe/London")
{:error, :invalid_datetime}
But in 2016 there was, so this is allowed provided the newest tzdata is available:
Calendar.DateTime.from_erl({{2016, 12, 31}, {23, 59, 60}}, "Europe/London")
{:ok, %DateTime{calendar: Calendar.ISO, day: 31, hour: 23, microsecond: {0, 0}, minute: 59, month: 12, second: 60, std_offset: 0, time_zone: "Europe/London", utc_offset: 0, year: 2016, zone_abbr: "GMT"}}
1