fix(date): use available timezone if any

[ccoVeille]

Description

It's important to use the date timezone if it has any.

Changes

Do not switch back to Local timezone if not needed

Fixes #81

Checklist

• I have read the CONTRIBUTING.md document.
• My code follows the code style of this project.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have updated the documentation accordingly.
• This change requires a change to the documentation on the website.

Additional Information

Timezones are always fun

[42atomys]

Hi, my turn for require package ! 😄

The catch of TZ in Date has something desired for future so nice addition

[ccoVeille]

There are more work to do. toDate is also affected by the "implicit" timezone conversion.

I started fixing locally, but now I'm busy IRL

[42atomys]

No problem @ccoVeille IRL > all
takes your time ! If you need help don't hesitate to ask me

[ccoVeille]

Added tests, fixed code, refactored a bit things that frustrated me

[42atomys]

@ccoVeille fyi : some issues on tests on CI

[ccoVeille]

I'm still able to learn things about how timezones are handled after a few decades 😓

And apparently, I'm not the only one
golang/go#56528

https://pkg.go.dev/time#Parse

When parsing a time with a zone offset like -0700, if the offset corresponds to a time zone used by the current location (Local), then Parse uses that location and zone in the returned time. Otherwise it records the time as being in a fabricated location with time fixed at the given zone offset.

When parsing a time with a zone abbreviation like MST, if the zone abbreviation has a defined offset in the current location, then that offset is used. The zone abbreviation "UTC" is recognized as UTC regardless of location. If the zone abbreviation is unknown, Parse records the time as being in a fabricated location with the given zone abbreviation and a zero offset. This choice means that such a time can be parsed and reformatted with the same layout losslessly, but the exact instant used in the representation will differ by the actual zone offset. To avoid such problems, prefer time layouts that use a numeric zone offset, or use ParseInLocation.

Said otherwise, the format displaying a zone in addition of the format causes troubles, the result varies between the timezone, and only the one matching the time.Local one will have a zone. So to test this, we must temporarily force the time.Local, and handle all the use cases.

Another solution could be rewritten the test to avoid using a format including the zone, the time offset could be enough.

[42atomys]

This kind of discovery are always interesting, discover something when dig deeper is a really good feeling

[ccoVeille]

@42atomys is there anything you wait from me?

[42atomys]

@ccoVeille No I don't, I just wait the "request review" but I assume you have just forgot, I will review now and go forward if all are good 🏁

[42atomys]

LGTM ✅

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Files with missing lines	Coverage Δ
handler.go	100.0% <100.0%> (ø)
pesticide/time_test_helpers.go	100.0% <100.0%> (ø)
registry/conversion/functions.go	100.0% <100.0%> (ø)
registry/time/functions.go	100.0% <100.0%> (ø)
registry/time/helpers.go	100.0% <100.0%> (ø)
sprigin/sprig_backward_compatibility.go	100.0% <100.0%> (ø)