Fixing 'UTC' did not equal 'Etc/UTC' failure on Mac

[JaroslavTulach]

Pull Request Description

Mitigates #7505 and makes sure CI passes again on our x64 based Mac OS X machines.

Checklist

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

• All code follows the Enso style guides.
• All code has been tested:
  • Unit tests have been written where possible.

[radeusgd]

If you want the check to pass, I think you need to remove the second added line, I'm pretty sure it will fail.

Definitely good to fix CI to pass, as always failing on Mac is not good - so I'm For merging this PR.

However, I would like to not close #7505. I think we should investigate why one system returns Etc/UTC and other just UTC.

Apparently they seem to be different names for the same concept...

Still, I'd like us to ensure that the line I just suggested you to remove actually works in longer term:

loose_zone_equal time.zone Time_Zone.utc

As a quick fix for CI - this is fine, but for longer-term it would be worth to investigate why there is this timezone inconsistency and fix it.

As users will definitely expect the TZ returned here to == Time_Zone.utc.

[JaroslavTulach]

There are two more [FAILED tests in the Mac OS X engine CI run:

• JavascriptDate: should handle shifting dates around spring DST edge cases
• JavascriptDataInArray: should handle shifting dates around spring DST edge cases

On my Mac the tests are skipped, but not on CI...

[JaroslavTulach]

Having CI green is important. I guess I merge now. @mwu-tow, can you make Mac OS X CI required again? Otherwise we are likely going to regress soon.