Fixes DateTime to handle extreme time zones

[muditchaudhary]

Overview

Fixes DateTime (#328) to support extreme time zones. Java DateTIme cannot handle extreme timezones (E.g., +2359, -2359). However, these are valid in Cedar. It now support all valid Cedar Datetime values 0000-01-01T00:00:00+2359 to 9999-12-31T23:59:59-2359.

Changes

• Introduces additional parsing methods to handle timezones instead of relying on Java DateTime.
• Adds comprehensive tests to validate the changes. Borrows some Datetime tests from Cedar-spec

[mark-creamer-amazon]

Had a double take as to why we're subtracting an offset here instead of adding

[muditchaudhary]

Ah yeah. this does look confusing.

For example, let's take this timestamp 10/23/2025-19:00::00 UTC. This is equivalent to 1,761,246,000,000 epochMillis.

For UTC-4:00 the equivalent timestamp for the above timestamp is 10/23/2025-15:00::00 UTC-4:00. So, their epochMillis should be equal. Now, let's say we want to convert 10/23/2025-15:00::00 UTC-4:00 to epochMillis.

This is how the code will do it:

1. Extract non-timezone part of the timestamp 10/23/2025-15:00::00, treat it as UTC and get its epochMillis i.e., 1,761,231,600,000. 1,761,231,600,000 (10/23/2025-15:00::00) < 1,761,246,000,000 (10/23/2025-19:00::00 UTC). So, this extracted epochMillis is behind the actual target value.
2. Calculate the millisecond offset of the timezone with sign i.e., -4:00 = -14,400,000.
3. Subtract the offset millisecond from epochMillis in Step 1 i.e., 1,761,231,600,000 - (-14,400,000) = 1761246000000 = 10/23/2025-19:00::00 UTC

So, eventually the offset is added when it is a negative offset (UTC is ahead) and subtracted when it is a positive (UTC is behind)