fix dst test failure

[GregoryTravis]

Pull Request Description

Fixes a test failure that depends on the date on which Daylight Saving Time changes.

Important Notes

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• All code has been tested:
  • Unit tests have been written where possible.
  • If GUI codebase was changed, the GUI was tested when built using ./run ide build.

[JaroslavTulach]

I believe that using Time_Zone.system makes the tests non-portable and should be eliminated. This change is thus a move towards the right direction as it removes usage of Time_Zone.system in one problematic (for Greg)Test.specify.

Clearly helps @GregoryTravis and the CI is green: let's integrate!

[JaroslavTulach]

I am surprised we are using Date_Time.new here and not create_new_datetime. That means we are testing only Enso implementation, not interop with other languages.

[radeusgd]

This is deliberate.

If we use create_new_datetime everywhere, we test how values from one language tested at given time interact with each other. By using Date_Time.new for the argument and still using create_new_datetime for the receiver (self = t1), we test how an Enso value interoperates with a value coming from another language - i.e. we check mixing of values from different languages with each other - which also needs to be supported as the values should all be interchangeable regardless of what language they come from.

I don't remember if this was added because there bugs with that or if it was just to ensure we test a wider range of scenarios, but surely it was done deliberately to test more interesting 'mixing' cases.

[radeusgd]

I'm wondering if instead of this, we should just make the default zone be utc in the test builders.

i.e.

Index: test/Tests/src/Data/Time/Date_Time_Spec.enso
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/test/Tests/src/Data/Time/Date_Time_Spec.enso b/test/Tests/src/Data/Time/Date_Time_Spec.enso
--- a/test/Tests/src/Data/Time/Date_Time_Spec.enso	(revision eb1550014b3c7120dc57ab111921eb7d18c2d5fe)
+++ b/test/Tests/src/Data/Time/Date_Time_Spec.enso	(date 1692868316355)
@@ -847,7 +847,7 @@
 
     Date_Part_Spec.spec name create_new_datetime
 
-js_datetime year month=1 day=1 hour=0 minute=0 second=0 nanosecond=0 zone=Time_Zone.system =
+js_datetime year month=1 day=1 hour=0 minute=0 second=0 nanosecond=0 zone=Time_Zone.utc =
     Panic.catch Any (js_datetime_with_zone year month day hour minute second nanosecond zone) (err -> Error.throw (Time_Error.Error err.payload))
 
 # This ensures that date returned by javascript has the right timezone specified by the zone parameter.
@@ -914,10 +914,10 @@
     else:
         return datetime.datetime(year, month, day, hour, minute, second, microseconds, Zone(zone, zone_name))
 
-enso_datetime year month=1 day=1 hour=0 minute=0 second=0 nanosecond=0 zone=Time_Zone.system =
+enso_datetime year month=1 day=1 hour=0 minute=0 second=0 nanosecond=0 zone=Time_Zone.utc =
     Date_Time.new year month day hour minute second nanosecond=nanosecond zone=zone
 
-java_datetime year month=1 day=1 hour=0 minute=0 second=0 nanosecond=0 zone=Time_Zone.system =
+java_datetime year month=1 day=1 hour=0 minute=0 second=0 nanosecond=0 zone=Time_Zone.utc =
     Panic.catch Any (ZonedDateTime.of year month day hour minute second nanosecond zone) (err -> Error.throw (Time_Error.Error <| err.payload.getMessage))
 
 maybe_parse_java_zoned text pattern=Nothing =

What do you think? This way new tests will be more likely to be written correctly.

[GregoryTravis]

I'll try it, but the test is currently failing for me on develop, for other reasons: #7655

[GregoryTravis]

Using this exact diff, I get 18 failures.