Fix Elixir compiler warnings for decreasing ranges without explicit steps

[cgrothaus]

Issue

Elixir 1.17 and 1.18 deprecated using decreasing Ranges without explicit steps.

See https://hexdocs.pm/elixir/1.17/changelog.html#4-hard-deprecations:

• [Range] left..right without explicit steps inside patterns and guards is deprecated, write left..right//step instead
• [Range] Decreasing ranges, such as 10..1 without an explicit step is deprecated, write 10..1//-1 instead

And https://hexdocs.pm/elixir/1.18/changelog.html#4-hard-deprecations:

• [Range] Deprecate inferring negative ranges on Range.new/2

Using implicit decreasing Ranges gives warnings like these:

warning: Range.new/2 and first..last default to a step of -1 when last < first. Use Range.new(first, last, -1) or first..last//-1, or pass 1 if that was your intention
  (tzdata 1.1.2) lib/tzdata/util.ex:67: Tzdata.Util.last_weekday_of_month/3
  (tzdata 1.1.2) lib/tzdata/util.ex:203: Tzdata.Util.tz_day_to_date/3
  (tzdata 1.1.2) lib/tzdata/util.ex:445: Tzdata.Util.time_for_rule/2
  (tzdata 1.1.2) lib/tzdata/far_future_dynamic_periods.ex:89: Tzdata.FarFutureDynamicPeriods.first_period_that_ends_in_year/2
  (tzdata 1.1.2) lib/tzdata/far_future_dynamic_periods.ex:27: Tzdata.FarFutureDynamicPeriods.periods_for_point_in_time/2
  (tzdata 1.1.2) lib/tzdata.ex:196: Tzdata.periods_for_time/3
  (tzdata 1.1.2) lib/tzdata/time_zone_database.ex:32: Tzdata.TimeZoneDatabase.time_zone_periods_from_wall_datetime/2
  (elixir 1.18.1) lib/calendar/datetime.ex:569: DateTime.from_naive/3
  (elixir 1.18.1) lib/calendar/datetime.ex:685: DateTime.from_naive!/3

Resolution

Use explicit //-1 step for decreasing Ranges.

[epinault]

@lau any chance we can get this one released? do you need help or more maintainers for this project? My company would be happy to provide some support

[cgrothaus]

Oh: https://github.com/lau/tzdata/actions/runs/12745831092/job/36702802217?pr=154#step:5:12

Do we have to differentiate the code between Elixir versions? Which versions are to be supported by the library?

[lau]

Thanks for the PR. The issue is that it breaks on older version of Elixir that are not that old.

I might have to drop support for older versions of Elixir. Not sure if it's worth it to do right now if it's "only" for something that is deprecated but still works.

[cgrothaus]

If I researched this correctly, the first..last//step syntax for ranges (Range.new/3), which is now soft-enforced with bespoke compiler warning for decreasing ranges, was introduced in Elixir 1.12.

Maybe we can solve this issue for all Elixir versions with conditional compilation? See effbb45.

@lau Would you approve the Github Actions CI workflow once again?

[cgrothaus]

Aside: the other test failure (https://github.com/lau/tzdata/actions/runs/12745831092/job/36702802574#step:7:17) is not related to my change. It is a doctest that fails because the current result of a Tzdata.periods/1 call deviates from the documented results for timezone Europe/Madrid. Maybe there have been timezone updates in the meanwhile? In any case, this would have to be solved in a different PR.

[epinault]

Thanks for the PR. The issue is that it breaks on older version of Elixir that are not that old.

I might have to drop support for older versions of Elixir. Not sure if it's worth it to do right now if it's "only" for something that is deprecated but still works.

it is hard deprecated in 1.17 https://hexdocs.pm/elixir/1.17.3/changelog.html#4-hard-deprecations (though it s not unsupported since but --warning-as-errors will fail for your library in CI )

I would agree that having a compile time fix as proposed would be great! We see tons of warning in our production system that we cannot remove

[codeadict]

Any plans to merge this @lau ?

[epinault]

@lau any update on this? again ,I am happy to help doing maintainer work with my company but would be nice to remove these constant warning in our production server