I think he also wants negative infinity, which won’t have a way to represent it using null. Using the database’s min and max date is the only way to do this.
mgwidmann
vlad.grb
I want to keep the data consistent, use exclude, check for containing, use both negative and positive infinities and have an index on this. So sure I could make multiple OR assuming that null has priority depending on the field like start_at , end_at and if end_at is null then it means an infinity. But I think that using infinity special values is much easier and more elegant way to concentrate on the general logic than on Boolean algebra.
0
Qqwy
TypeCheck Core Team
If you are using Postgres it might be possible to define your own compound data type. You will probably lose some of the built-in datetime-related functionality though, probably.
I currently like @jwarlander’s solution (of using two dates that are not relevant to your business domain because they lie so far in the past/future as -infinity and infinity respectively) because that will keep all existing date-logic working.
3
axelson
Scenic Core Team
Could you make use of the Postgres type tsrange? This would be instead of storing two dates separately.
I believe it even supports unbounded ranges:
1
vlad.grb
Could you make use of the Postgres type
tsrange?
That was the plan. daterange uses date as a scalar type for the range and infinity is still the issue.
1
wojtekmach
Hex Core Team
As you’ve shown it’s possible to build a custom Postgrex extension which could even map Postgres infinity to Elixir :infinity atom and have a Ecto custom type on top of that. However, this :infinity value wouldn’t work with any of the Date.* functions from standard library, e.g. you couldn’t do Date.compare(date, :infinity) which I think will severely limit usefulness of this.
I think limiting range of possible values to 0000-01-01/9999-12-31 (or whatever you want to arbitrarily pick) is a pragmatic choice.
I’d be curious to hear what’s your actual use case for an infinity value, do you have a particular table and column name in mind that would hold such value?
Btw, regarding:
%Inspect.Error{
message: “got ArgumentError with message "argument error" while inspecting %{struct: Date, calendar: Calendar.ISO, day: 11, month: 7, year: 5881610}”
}
This works on recent Elixir versions:
% elixir --version
Elixir 1.9.0-dev
iex> %{__struct__: Date, calendar: Calendar.ISO, day: 11, month: 7, year: 5881610}
~D[5881610-07-11]
1
vlad.grb
This works on recent Elixir versions:
For sure I can’t jump from 1.6 to 1.9 
I’d be curious to hear what’s your actual use case for an infinity value
In general it is a schedule with weekly timings. And the schedule could be limited ex: from 1 March to 1 June and limitless aka yearly.
I think limiting range of possible values to 0000-01-01/9999-12-31 (or whatever you want to arbitrarily pick) is a pragmatic choice.
Yeah, I am thinking it is only the existing way right now. But I hope that core team took a note on this since it is useful functionality and as I imagine is just a matter of:
field_db_value = case date do
Date.positive_infinity -> "infinity"
Date.negative_infinity -> "-infinity"
date -> "date parts as was"
end
0
mancubus
Not exactly.
Postgrex tries to convert to NaiveDateTime with Calendar.ISO being its default calendar.
Since the notion of “infinity” in postgres is just another value (link), it arrives as some date in the super distant future (eg. year 294277). This fails because of this validation in Calendar.ISO, which just does not allow years greater than 9999.
2
Fire-Dragon-DoL
I stumbled upon this issue too. -infinity and +infinity are perfectly valid dates in Postgres and it brings a lot of advantages using them (default values especially) rather than using fixed dates.
I could understand a problem if they came back as actual strings on the adapter, but instead they come back as valid timestamps, both negative and positive, Calendar.ISO however is limit the year to -9999 → 9999, but this is very arbitrary.
What if I’m modeling a game set into the future, or in a time traveling fashion? Or more simply, what if I’m modeling a website about history? Wikipedia says that human existed over 2.8 millions years ago.
1
Qqwy
TypeCheck Core Team
Then it is very probable that ‘Calendar.ISO’ is not the thing you want. Instead, what about creating your own Calendar implementation (which might heavily lean on the functions provided by Calendar.ISO.) combined with your own custom Ecto.Type so Ecto knows to use your calendar module rather than Calendar.ISO.
I believe the restriction on -9999...9999 was put in place to simplify the parsing of the year part of the date (i.e. by being more strict/conservative in the format the year part could take).
2