--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4J56c%3DGxVgiSMH7Kd3K1ZYSvxMAj8H_qnWSwEbbf%3Dc_9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAP%3DvNq9UcWOvOqVrhJ70KQh8OWW0zwRBs%3DPBY-XWqAn%2BaLNu1A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/56E84B73.1060106%40wildgooses.com.
--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/e51829a8-918c-489b-8a29-e85c7f1d79e5%40googlegroups.com.
Although the year starts on July 1st, we still only increase the year from Dec 31st -> Jan 1st, correct?
You received this message because you are subscribed to a topic in the Google Groups "elixir-lang-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elixir-lang-core/KvJQaUcUlOk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JFDdtYXWPiHhTqRhpybS3T_D2_HjjEgjUKtzjnHcS2AA%40mail.gmail.com.
This is even a small ambiguity in an ISO calendar since the question of “first day of the year” depends on whether you mean the first day of the first week, or the first day of January.
But if your calendar starts on “first thursday of april” then the last day can only really be encoded as {m, y} in the gregorian calendar because the notion of a month in this calendar does not align with a gregorian month boundary. I suppose that if the definition of `last_day_of_month` was changed to mean “number of days in a month” then this type of calendar could be implemented without change and still be compliant with the calendar behaviour.
But I would still need some way to define configuration. How do I capture that my version of Calendar.FiscalYear starts on July 1st, and another one starts on April 1st. All other rules are the same - just a different start date.
FiscalYear.define(MyApp.AprilCalendar, starts_at: "foo", ends_at: "bar")
FiscalYear.define(MyApp.AprilBased, starts_at: "foo", ends_at: "bar")
I think the idea of representing a date as a {y, m, d} is effectively an encoding mechanism that happens to be the same as the proleptic Gregorian calendar - a case which matches the calendar in use by a lot of people thereby making it convenient and easy and I’m not proposing any alternative to that.
--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JzQOf2F-sO%2BZy4dYo%2Bn-UqOph7eer5dpLqD9TxJ8brPA%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "elixir-lang-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elixir-lang-core/KvJQaUcUlOk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JzQOf2F-sO%2BZy4dYo%2Bn-UqOph7eer5dpLqD9TxJ8brPA%40mail.gmail.com.
@spec compare(Calendar.date, Calendar.date) :: :lt | :eq | :gt
def compare(date1, date2) do
case {to_erl(date1), to_erl(date2)} do
{first, second} when first > second -> :gt
{first, second} when first < second -> :lt
_ -> :eq
end
end
This assumes that the date encoding has the same meaning across calendars and that
the {y, m, d} are always ISO representations (or at least the same representation)
(a) Is the design intent that all Calendars use the {y, m, d} to represent an ISO
date and
therefore internally convert when required?
(b) Calendars are free to use {y, m, d} for different non-ISO encodings and therefore
Date.compare and others should be adjusted to be calendar agnostic? |
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4J_wV%3DtzXdjUubrYpi_fgPOSa39eG0CAwa0y3F3oMvGGw%40mail.gmail.com.
You received this message because you are subscribed to a topic in the Google Groups "elixir-lang-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elixir-lang-core/KvJQaUcUlOk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAK%3D%2B-Tu9HxoYxnvc7Q-2cPgXLW3U1Y6edBv1yo%3DD0ar16Aqs6A%40mail.gmail.com.
José, Paul, thanks both.José: option (b) would seem better to me as well - and it means my work is not (yet?) in vain :-)Paul: I’m working on calendrical calculations for Elixir and want to be Calendar behaviour compatible. I think some small and compatible adjustments to Date and DateTime/NaiveDateTime can allow all of the calendars in Calendrical Calculations to be developed in accordance with the behaviour except those that don’t reduce to a {y, m, d} tuple - like the Balinese calendar. Including Date.to_fixed() would be a necessary part of that as a way of allowing date comparisons and calendar conversions. Which can be done with no performance impact to Calendar. ISO I believe.With the guidance from José in this thread I can finish up development now and see if the community thinks its worth a PR. Of course calendars beyond the standard ISO would be a separate package(s) and any changes will have to have the same or better performance profile and pass all current tests too.Perhaps its a quirk, but I happen to really like calendar stuff - its the relationship to human history I think.
Oh, and I’m not proposing the
On 20 Dec 2016, at 9:51 AM, Paul Schoenfelder <paulscho...@gmail.com> wrote:
I think a good approach would be to define a reference date, from which all calendars can use as a point to convert to and from. This method is used in the book Calendrical Calculations, and their associated Java/Scheme implementation called Calendrica (which includes Egyptian/Armenian, Gregorian, Julian, Coptic/Ethiopic, ISO, Islamic, Hebrew, Ecclesiastical, Hindu, Mayan, Balinese Pawukon, Persian, French Revolutionary, and Chinese calendars). It works by defining a "fixed" calendar, which starts with day 1, and then defining conversions to and from the "fixed" calendar by using the number of days relative to that calendar. In Calendrica, the start of "fixed" date 1 is the same as the start of the Gregorian (proleptic) calendar, e.g. midnight of January 1st, year 1, thus to_fixed({1,1,1}) == 1. Since the passage of time can be represented as days -1, 0, 1, 2, ..N relative to the fixed calendar, this provides a way to convert between any set of calendars, by simply converting to the fixed calendar, and then converting to the destination calendar. Time is similarly treated, as each calendar also defines the point in time at which a day "starts", so conversions are all unified to occur at noon. Since in many calendars this is based on location, it is up to the calendar implementation to convert to noon prior to doing conversions to another calendar. There is a great deal more that goes into it, but hopefully it at least sparks some discussion about how to approach this. In my opinion, it's the best approach I've come across so far (and I wouldn't be surprised if it's effectively the only workable approach).Paul
It is option B.If we don't delegate to the calendar implementation, we always hardcode to Calendar.ISO. This way users of other calendars get a hard failure and we can discuss how to best move forward. So if you look at the "to_erl" implementation, you will see that it only supports Calendar.ISO.This means it is time to have the conversation. :) We have two options:1. Make "to_erl" part of the calendar behaviour. However, since the Erlang representation is a Proleptic Gregorian calendar, to_erl would effectively be a conversion to gregorian.2. Make date_compare and naive_date_time_compare part of the calendar behaviour.One question you may know the answer: are calendar conversions bijective? For example, is a date in one calendar guaranteed to represent a single date in another calendar and vice-versa? I would think that yes, because of time, but never underestimate calendars. But if yes, we could convert dates to a known calendar (Proleptic Gregorian) and then compare them (solution 1). This would also allow comparisons between calendars (which again, requires them to be bijective).
--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4J_wV%3DtzXdjUubrYpi_fgPOSa39eG0CAwa0y3F3oMvGGw%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "elixir-lang-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elixir-lang-core/KvJQaUcUlOk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elixir-lang-core+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAK%3D%2B-Tu9HxoYxnvc7Q-2cPgXLW3U1Y6edBv1yo%3DD0ar16Aqs6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/1190677D-C0A7-4F33-8CD2-A5B7EC32835D%40gmail.com.
To unsubscribe from this group and all its topics, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JBze9basD93GwzUtfAeeiV1uaozC_wMeJm1fG4ChU7hg%40mail.gmail.com.