Notice by @qqwy: This topic was split from the Calendars & Calendar Conversions topic, which is about how calendars should be implemented inside Elixir Core. The idea of a separate ex_calendar library started with this post by @OvermindDL1:
Just a brain dump here since I am sick. ^.^
Not all Calendars use a year/month/day/hour/minute/second/etc… construct, so putting that as a base-most Date/DateTime structs was a very very bad move. Each Calendar should have its own Date/DateTime structs, which also allows easy matching on:
def do_blah(%Calendar.Gregorian{year: year, month: month, day: day}), do: gregorianStuff(year, month, day)
def do_blah(%Calendar.Bloop{egrek: egrek, vreenoop: vreenoop}), do: bloopStuff(egrek, vreenoop)
# Using expede's type_class (finally hit 1.0.0 whoo!) style here to force a set of generic conversions for calendar types
def do_blah(someOtherCalendar), do: Calendar.convertToCalendar(Calendar.Gregorian) |> do_blah
The above last line should use a direct conversion if one exists from calendar type to the given calendar type, else it should fall back to a mandatory conversion to some universal time storage type that could be something like: %UniversalTime{attosecondsSinceBaseTimeInObject:int, baseObject:atom|binary} where attosecondsSinceBaseTimeInObject would be the number of attoseconds since some arbitrary base period for the given baseObject, which could be its existence setup or something, and baseObject is the relative object that the relative time is for, which would default to :earth or so. Converting a UniversalTime for an object like :mars to some calendar like Calendar.Gregorian makes no sense and should exception or something, instead you’d need to calculate the relative earth time from mars first, also handled by the type_class/protocol by getting the relative calculations from the objects based on velocity and such, but for something like :earth/:mars you could pretend that is just 0 probably, this is all internal stuff that an external user would not use directly in most cases of course, though if you are making a relativistic simulation it could be quite useful externally, but mostly it is just for calendar conversions.
TL;DR: Date/DateTime should not be a global structure, every calendar could potentially represent Date/DateTime differently and they should be calendar specific. You can use protocols or type_class’s or so to get generic information out of ‘any’ calendar of course.
I’m going to lay back down for a bit. ^.^
