> DateTime.is?(a, operator, b), when operator :lt | :le | :eq | :ge | :gt,
which would capture the :le and :ge options.
> I like the :inclusive option if the need ever arises.
If we combine these proposals, we'd only need the exact options that
DateTime.compare already returns (:lt | :eq | :gt).
I also prefer the look of something like :> or :less_than, but I think the
consistency's more important in this scenario; DateTime.compare and
DateTime.is? should be in sync.
On Monday, October 31, 2022 at 1:16:52 PM UTC-4 José Valim wrote:
> I am not worried about the argument order because in Elixir the subject is
> always the first argument. So it is always "is date1 before date2?". I like
> the :inclusive option if the need ever arises.
>
> DateTime.compare(a, :<, b) would get my vote of the alternative proposals
> but I think it doesn't move much the needle in comparison to
> DateTime.compare.
>
> On Mon, Oct 31, 2022 at 5:44 PM Cliff <notcliff...@gmail.com> wrote:
>
>> I would prefer the atoms *:before*, and *:after* rather than
>> :gt/:greater_than/etc. Since we're already solving the problem of
>> operator/argument ordering, why not remove the final mental barrier of
>> reasoning about whether a time being "greater than" another time means that
>> it is before or after? *foo(a, :gt, b)* still requires a second thought
>> ("Is a bigger time earlier or later?"), whereas if I read code that said
>> *foo(a,
>> :before, b)* I would feel confident in my understanding after only the
>> first read.
>>
>> On Monday, October 31, 2022 at 12:35:05 PM UTC-4 lui...@gmail.com wrote:
>>
>>> I also prefer something like *DateTime.compare(a, operator, b)*.
>>>
>>> Operators don't need to be *cryptic* like *:eq*, *:gt*, *:lte*, etc.,
>>> we can use the same comparison operators we already are used to:
>>>
>>> *DateTime.compare(a, :<, b)*
>>> *DateTime.compare(a, :==, b)*
>>> *DateTime.compare(a, :>=, b)*
>>>
>>> It's clear and much less verbose than the Ecto's (which was a great
>>> suggestion, by the way).
>>>
>>> On Monday, October 31, 2022 at 5:23:54 PM UTC+1 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-co...@googlegroups.com.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/7435b979-d0eb-4726-aa65-a94ada53d320n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/elixir-lang-core/7435b979-d0eb-4726-aa65-a94ada53d320n%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-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/5ea3514b-e6bb-4d81-b09a-e48439194aadn%40googlegroups.com.
