I could also see myself using *a |> DateTime.before?(b)* On Monday, October 31, 2022 at 12:23:54 PM UTC-4 and...@dryga.com wrote:
> Hey guys, as an idea why don't we reuse atoms from Ecto: > > - :less_than > - :greater_than > - :less_than_or_equal_to > - :greater_than_or_equal_to > - :equal_to > - :not_equal_to > > I feel like they are fairly common nowadays and even though it's more to > type make it easier to understand when you want an inclusive comparison. > > We can later make it part of all modules that have `compare/2` (Date, > DateTime, Time, Version, etc). > > On Monday, October 31, 2022 at 10:10:09 AM UTC-6 Cliff wrote: > >> I prefer the form *DateTime.is(a, operator, b)*, but I agree with others >> that it would need a more sensible name than "is". >> >> Regarding the form *DateTime.before?(a, b)*, I could still see myself >> getting confused by argument order. *before?(a, b)* might be read as >> "before A happened, B happened", rather than the intended "A happened >> before B". the *is(a, :before, b)* form, however, is read exactly how it >> would be spoken. >> >> Regarding comparison inclusivity, another possibility is a keyword >> option: *DateTime.before?(a, b, inclusive: true)* >> >> On Monday, October 31, 2022 at 3:45:15 AM UTC-4 simonmc...@gmail.com >> wrote: >> >>> DateTime.before?(a, b) is much nicer than DateTime.compare(a, b) == >>> :lt. It doesn't completely remove the argument order issue but I reckon it >>> would resolve it for me. I run DateTime.compare(a, b) in iex every time I >>> use the function because I'm terribly forgetful and paranoid. I would >>> prefer DateTime.eq?/lt?/le?/gt?/ge? instead of >>> before?/after?/on_or_before?/on_or_after? which is shorter, matches >>> compare/2 and might allow the le/ge equivalents to sneak through. I think >>> it would be a shame to leave out le and ge. >>> >>> DateTime.is?/compare?(a, :lt, b) is a whole lot less ambiguous to me. >>> It reads how you would write it in maths or spoken language. >>> >>> On Monday, 31 October 2022 at 5:08:35 pm UTC+10 zachary....@gmail.com >>> wrote: >>> >>>> I wonder how much of the issue is the Api and how much of the issue is >>>> just the docs? I.e its not a given that all arguments in every position >>>> always make sense, but we typically rely on things like elixir_ls to help >>>> us when the answer isn't obvious. >>>> >>>> Could we perhaps just improve the docs in some way? i.e update the >>>> specs to say `datetime :: Calendar.datetime(), compares_to :: >>>> Calendar.datetime()`, and have the args say `compare(datetime, >>>> compares_to)` and have part of the first line of text say something a bit >>>> more informative? >>>> >>>> >>>> On Mon, Oct 31, 2022 at 3:02 AM, Jon Rowe <ma...@jonrowe.co.uk> wrote: >>>> >>>>> I'm not sure the name is right, but I like >>>>> >>>>> DateTime.is?(a <http://datetime.is/?(a>, operator, b), when operator >>>>> :lt | :le | :eq | :ge | :gt, which would capture the :le and :ge options. >>>>> >>>>> >>>>> As a usage api, we could actually have `compare?/3` especially as the >>>>> name doesn't overlap with `compare/2` which would hopefully alleviate >>>>> anyones concerns about the return type changing >>>>> >>>>> On Mon, 31 Oct 2022, at 6:23 AM, José Valim wrote: >>>>> >>>> My thought process is that a simple to use API should be the focus, >>>>> because we already have a complete API in Date.compare/2 >>>>> <http://date.compare/2> and friends. >>>>> >>>>> On Mon, Oct 31, 2022 at 02:16 Simon McConnell <simonmc...@gmail.com> >>>>> wrote: >>>>> >>>>> would we want on_or_after? and on_or_before? as well then? Or >>>>> something like DateTime.is?(a <http://datetime.is/?(a>, operator, b), >>>>> when operator :lt | :le | :eq | :ge | :gt, which would capture the :le >>>>> and >>>>> :ge options. >>>>> >>>>> On Monday, 31 October 2022 at 7:26:42 am UTC+10 José Valim wrote: >>>>> >>>>> Thank you! >>>>> >>>>> A PR that adds before?/after? to Time, Date, NaiveDateTime, and >>>>> DateTime is welcome! >>>>> >>>>> >>>>> On Sun, Oct 30, 2022 at 6:46 PM Cliff <notcliff...@gmail.com> wrote: >>>>> >>>>> I did a bit of research. Many other languages use some form of >>>>> operator overloading to do datetime comparison. The ones that do >>>>> something >>>>> different: >>>>> >>>>> - Java has LocalDateTime.compareTo(other) >>>>> >>>>> <https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/LocalDateTime.html#compareTo(java.time.chrono.ChronoLocalDateTime)>, >>>>> >>>>> returning an integer representing gt/lt/eq. There is also >>>>> LocalDateTime.isBefore(other) >>>>> >>>>> <https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/LocalDateTime.html#isBefore(java.time.chrono.ChronoLocalDateTime)>, >>>>> >>>>> LocalDateTime.isAfter(other), and LocalDateTime.isEqual(other). The >>>>> LocalDateTime.is <http://localdatetime.is/>{Before, After} methods >>>>> are non-inclusive (<, >) comparisons. They are instance methods, so >>>>> usage >>>>> is like `myTime1.isBefore(myTime2)` >>>>> - OCaml's "calendar" library provides a Date.compare >>>>> >>>>> <https://ocaml.org/p/calendar/3.0.0/doc/CalendarLib/Date/index.html#val-compare> >>>>> >>>>> function that returns an integer representing gt/lt/eq (for use in >>>>> OCaml's >>>>> List.sort function, which sorts a list according to the provided >>>>> comparison >>>>> function). It also provides Date.> >>>>> >>>>> <https://ocaml.org/p/calendar/3.0.0/doc/CalendarLib/Date/index.html#val-(%3E)>, >>>>> >>>>> and Date.>= >>>>> >>>>> <https://ocaml.org/p/calendar/3.0.0/doc/CalendarLib/Date/index.html#val-(%3E=)>, >>>>> >>>>> etc. Worth noting is that OCaml allows you to do expression-level >>>>> module >>>>> imports, like *Date.(my_t1 > my_t2)* to use Date's *>* function in >>>>> the parenthesized expression without needing to *open Date* in the >>>>> entire scope ("open" is OCaml's "import") - this could potentially be >>>>> possible in Elixir using a macro? >>>>> - Golang: t1.After(t2) <https://pkg.go.dev/time#Time.After>, >>>>> t1.Before(t2), t1.Equal(t2). Non-inclusive (> and <). >>>>> - Clojure clj-time library: (after? t1 t2) >>>>> >>>>> <https://clj-time.github.io/clj-time/doc/clj-time.core.html#var-after.3F>, >>>>> >>>>> (before? t1 t2) >>>>> >>>>> <https://clj-time.github.io/clj-time/doc/clj-time.core.html#var-before.3F>, >>>>> >>>>> and (equal? t1 t2) >>>>> >>>>> <https://clj-time.github.io/clj-time/doc/clj-time.core.html#var-equal.3F>. >>>>> >>>>> IMO the argument order is still confusing in these. >>>>> >>>>> >>>>> >>>>> >>>>> On Sunday, October 30, 2022 at 3:15:14 AM UTC-4 José Valim wrote: >>>>> >>>>> I am definitely in favor of clearer APIs. >>>>> >>>>> However, it would probably be best to explore how different libraries >>>>> in different languages tackle this. Can you please explore this? In >>>>> particular, I am curious to know if before/after mean "<" and ">" >>>>> respectively or if they mean "<=" and "=>" (I assume the former). And >>>>> also >>>>> if some libraries feel compelled to expose functions such as >>>>> "after_or_equal" or if users would have to write Date.equal?(date1, >>>>> date2) >>>>> or Date.earlier?(date1, date2), which would end-up doing the double of >>>>> conversions. >>>>> >>>>> >>>>> >>>>> -- >>>>> 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/fcd07389-c6a0-497d-9c09-7f1eacf620c6n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/elixir-lang-core/fcd07389-c6a0-497d-9c09-7f1eacf620c6n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> >>>>> -- >>>>> 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/e6c55604-c3ea-464c-908c-5a6092f4d8edn%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/elixir-lang-core/e6c55604-c3ea-464c-908c-5a6092f4d8edn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> >>>>> -- >>>>> 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/CAGnRm4%2ByT9jA7uqGX0Cyapgfx0AjW%2BU_d4Ai-NQ6vD9UsEb2uQ%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2ByT9jA7uqGX0Cyapgfx0AjW%2BU_d4Ai-NQ6vD9UsEb2uQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> -- >>>>> 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/2e821e87-6ee0-4702-b69f-e2616b61b1dd%40app.fastmail.com >>>>> >>>>> <https://groups.google.com/d/msgid/elixir-lang-core/2e821e87-6ee0-4702-b69f-e2616b61b1dd%40app.fastmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>>> -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/acc9da46-63a2-4d80-a989-77967ead7738n%40googlegroups.com.
