Calculating the beginning of next month

adamu

I’m having a discussion with a colleague about how to calculate the beginning of the next month given a certain Date using the core library. We have come up with two solutions, but cannot agree on which one is better. Are there any technical reasons to prefer one over the other here? Or better options (without using external libraries)?

Version that relies on using the calendar to calculate the number of days to the next month:

def beginning_of_next_month(%Date{} = date) do
  days_in_month = Date.days_in_month(date)

  date
  |> Date.beginning_of_month()
  |> Date.add(days_in_month)
end

Version that increments the month and relies on pattern matching to handle rolling over the year:

def beginning_of_next_month(%Date{year: year, month: 12}),
  do: Date.new!(year + 1, 1, 1)

def beginning_of_next_month(%Date{year: year, month: month}),
  do: Date.new!(year, month + 1, 1)

Date.days_in_month/1 + Date.add/2
Pattern match + Date.new/3

0 voters

12 comments

#dates #date

1 2559 12

2022-01-27 16:11:56 UTC

Showing Posts 1 to 10

Show Best Posts
Show All (oldest first)
Show All (newest first)

c4710n

I prefer version 1 - it uses the public API of Date. It is stable. If it is depracated, compiler will warn you about that.

version 2 relies on the structure of Date struct. Generally, I think it is the moving part, and will change potentially in the future. (although the probability is very low)

Post #1

qhwa

I like the increment version but I think it’s incorrect because the day should be always 1.

I’ll probably write:

def beginning_of_next_month(%Date{year: year, month: 12}),
  do: %{date | year: year + 1, month: 1, day: 1}

def beginning_of_next_month(%Date{month: month}),
  do: %{date | month: month + 1, day: 1}

Simple math seems clearer than public API combos to me.
Anyway, it feels good to have Date.beginning_of_next_month/1 out of the box.

Post #2

adamu

Thanks for the correction, have fixed it. That’ll teach me to re-write things for the purposes of posting here - introduced a bug in the process.

But, for your version, my understanding is that manually updating the Date struct is bad practice - because it bypasses the checks for invalid dates provided by functions such as Date.new!. Using Date.new! is why the 2nd version receives the year also.

Hmm, so that’s one each so far…

Post #3

trisolaran

Personally, I’d go for:

date
|> Date.end_of_month()
|> Date.add(1)

Post #4

soup

I find the first simpler to understand. I think it may also may handle non Gregorian calendars “for free” where as the pattern matched makes assumptions on the underlying calendar at play? Not something I have actually tested.

Pretty esoteric argument though, in most cases.

Post #5

eksperimental

Even simpler:
~D[2000-01-01] |> Date.end_of_month() |> Date.add(1)

Post #6

eksperimental

Funny fact, we wrote the same solution.

Post #7

adamu

Perfect. I completely missed Date.end_of_month

Post #8

trisolaran

hehe true! Sometimes it’s just a matter of who can type faster

Post #9

jdumont

I’ve had similar debates about how best to find the next date matching a given pattern.

e.g. Today is Wednesday 26 Jan 2022, what is the date of the next (and every following) Friday and Monday?

I found this simple with Swift thanks to some very sophisticated calendar APIs available, but couldn’t find a decent solution that didn’t make any assumptions about the particular calendar in use when I came back to Elixir.

I ended up with a similar solution to @trisolaran where I would move from my current date to a known point and work from there, but the pattern matched function calls got really fiddly to account for all the possible patterns I wanted to calculate. It was never something I was confident in.

Post #10

Load more posts (2 remaining)