-
Notifications
You must be signed in to change notification settings - Fork 3.4k
WIP: Implement big year parsing #13720
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
when calendar == Calendar.ISO do | ||
"Date.new!(#{Integer.to_string(year)}, #{Integer.to_string(month)}, #{Integer.to_string(day)})" | ||
when year in -9999..9999 do | ||
"~D[" <> calendar.date_to_string(year, month, day) <> suffix(calendar) <> "]" | ||
end | ||
|
||
def inspect(%{calendar: calendar, year: year, month: month, day: day}, _) do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should remove this clause and the guards. Just always invoke calendar.date_to_string
. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking that, but wanted to avoid a situation where a particular calendar implementation is inadvertently relying on year being in -9999..9999
. I know there is a Jalaali calendar implementation I can test, not sure if there are others,
@@ -216,6 +216,22 @@ defmodule Calendar.ISO do | |||
] | |||
end | |||
|
|||
[match_big_year, guard_big_year, match_big_year_rest, guard_big_year_rest, read_big_year_rest] = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about this: every time we see a + or - sign, we use Integer.parse to extract the year and then we parse the rest (month/day) using the patterns below? Would that simplify things a bit? But the general direction is good to me.
WIP, but please critique. See #13712