Error handling conversions which land in a > 4 digit year

[thomas9911]

Steps to reproduce

• Timex.to_datetime(~N[9999-12-31T23:59:59], "Europe/Amsterdam")

Description of issue

On one project im working on uses Timex version '3.6.4' and on another project I use the latest version '3.7.9'. On '3.6.4' this returns #DateTime<9999-12-31 23:59:59+01:00 CET Europe/Amsterdam> and on '3.7.9' this raises with

** (ArgumentError) cannot convert {{10000, 3, 26}, {2, 0, 0}} to naive datetime, reason: :invalid_date
    (elixir 1.13.1) lib/calendar/naive_datetime.ex:839: NaiveDateTime.from_erl!/3
    (tzdata 1.1.1) lib/tzdata/time_zone_database.ex:101: Tzdata.TimeZoneDatabase.old_tz_period_to_new/1
    (tzdata 1.1.1) lib/tzdata/time_zone_database.ex:34: Tzdata.TimeZoneDatabase.time_zone_periods_from_wall_datetime/2
    (timex 3.7.9) lib/timezone/database.ex:37: Timex.Timezone.Database.time_zone_periods_from_wall_datetime/2
    (elixir 1.13.1) lib/calendar/datetime.ex:491: DateTime.from_naive/3
    (timex 3.7.9) lib/timezone/timezone.ex:573: Timex.Timezone.convert/2
    (timex 3.7.9) lib/datetime/naivedatetime.ex:35: Timex.Protocol.NaiveDateTime.to_datetime/2

Is this a known issue?

Edit: Did some more digging and "Europe/Athens" has this issue as well but "Europe/Istanbul" doesnt (they are in the same timezone +3:00). Maybe something with daylight savings?

[bitwalker]

This is failing because there is no support in the underlying standard library APIs for years with more than 4 digits, and this particular conversion lands in the year 10000. Unfortunately, this isn't being handled gracefully in tzdata. I'm not sure there is much I can do about this - this should probably be fixed in tzdata, but even tzdata will be in a tough spot, because the "real" constraint here is in the Elixir and Erlang standard libraries.

That said, is there a real necessity for creating dates ~7900 years in the future in your project? I mean, I would agree it should be handled gracefully, but on the other hand, this is an extreme edge case. I wouldn't be surprised if the general reaction to this from the Erlang/OTP team is "don't do that" (and Elixir largely inherits the constraints imposed by the Erlang standard library).

NOTE: As far as the change in behavior goes, as bugs have been addressed in some of the Timex internals over time, some conversions that appeared to work previously, no longer do, and that's because the previous conversions were incorrect in some way. That's not to say that there aren't additional bugs remaining, just that this is why you might observe something like your example working in a previous version, but breaking in the latest version.

[thomas9911]

Sounds good.

a real necessity for creating dates ~7900 years in the future in your project

I also told my customers this 😂. I now catch the exception in my code, so for me this problem is handled. This ticket was more to inform you of this bug / edge case.