Calculating the beginning of next month

Questions / Help
,
1

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

1 Like
2

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)

4 Likes
3

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.

1 Like
4

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… :thinking:

5

Personally, I’d go for:

date
|> Date.end_of_month()
|> Date.add(1)
11 Likes
6

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.

7

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

6 Likes
8

Funny fact, we wrote the same solution.

2 Likes
9

Perfect. I completely missed Date.end_of_month :man_facepalming:

2 Likes
10

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

1 Like
11

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.

12

If you’re after generalised calendar support, ex_cldr_calendars has quite a lot of capability:

  • User definable month- and week-based Gregorian-derived calendars (think ISOWeek calendar, 445/454/445 calendars, fiscal year calendars for countries and so on)
  • Julian, Coptic, Persian, Ethiopian calendars
  • Lunisolar calendars (Chinese, Japanese and Korean) coming on Lunar New Years Day (next week)

Recurring events is not yet something it supports however I am still working on a library called Tempo that has built in support for recurring events for arbitrary calendars.

1 Like
13

That looks to be exactly what I’m after! All of my recurring events are based on either weekly, monthly or annual occurrences so ex_cldr_calendars is perfect. The weekend? function in particular I see being useful.

Thank you!