Define Enso epoch start as 15th October 1582.

[Akirathan]

Pull Request Description

Define start of Enso epoch as 15th of October 1582 - start of the Gregorian calendar.

Important Notes

• Some (Gregorian) calendar related functionalities within Date and Date_Time now produces a warning if the receiving Date/Date_Time is before the epoch start, e.g., week_of_year, is_leap_year, etc.

Checklist

Please include the following checklist in your PR:

• The documentation has been updated if necessary.
• All code conforms to the
  Scala,
  Java,
  and
  Rust
  style guides.
• All code has been tested:
  • Unit tests have been written where possible.
  • If GUI codebase was changed: Enso GUI was tested when built using BOTH
    ./run ide build and ./run ide watch.

[radeusgd]

Code looks good to me overall, although the tests need to be amended because currently they do not test stuff.

I also have a few suggestions how to make things a bit clearer (in my subjective opinion), however the current way is also mostly good. The only strong thing is the big workdays functions - I think in the current form it is hard to keep track if all codepaths correctly check for the epoch and I'd like that to be clear to avoid bugs.

One last thing - from the earlier discussions I was not sure if we want to return the dataflow error for these operations. My initial understanding was that we allow to return a result, but attach a dataflow warning to such an operation saying that the result cannot be trusted. This is a bit more permissive as the user can still use the operations, they are just warned that results may be wrong. It is a bit more dangerous as it's easier to remove the warnings though. I have no opinion on this, @jdunkerley what was the idea here? Do we want dataflow errors or warnings?

[Akirathan]

One last thing - from the earlier discussions I was not sure if we want to return the dataflow error for these operations. My initial understanding was that we allow to return a result, but attach a dataflow warning to such an operation saying that the result cannot be trusted. This is a bit more permissive as the user can still use the operations, they are just warned that results may be wrong. It is a bit more dangerous as it's easier to remove the warnings though. I have no opinion on this, @jdunkerley what was the idea here? Do we want dataflow errors or warnings?

The original idea was to use warnings. I will change the behavior so that the methods that fail with an exception in the underlying java methods will fail with an error, and all the other methods that now fail with error, will just attach a warning instead. So that, e.g., trying to get number of days for a Date_Time that is before the epoch will attach a warning and won't fail with an error.

[jdunkerley]

One last thing - from the earlier discussions I was not sure if we want to return the dataflow error for these operations. My initial understanding was that we allow to return a result, but attach a dataflow warning to such an operation saying that the result cannot be trusted. This is a bit more permissive as the user can still use the operations, they are just warned that results may be wrong. It is a bit more dangerous as it's easier to remove the warnings though. I have no opinion on this, @jdunkerley what was the idea here? Do we want dataflow errors or warnings?

Yes the suggestion was to return the values with a warning attached. This would allow the users to perform the computation but warn that the values are possibly wrong.

[hubertp]

LGTM re engine changes

[radeusgd]

Looks good, but I think it would be good to wrap the warnings in some Atom instead of using raw texts. Plus a few very minor nitpicks.