ZonedDateTime parse functions are a pain to use

[sffc]

try_from_str calculates the variant, but it is strict about what fields should be there.

try_loose_from_str is more lenient, but it doesn't calculate the variant.

My input string is "2000-01-01T00:00Z[Etc/GMT]" and try_from_str doesn't like it.

@robertbastian

[sffc]

Maybe this is being caused by the Z.

[sffc]

CC @nekevss

[sffc]

The change i want to implement is a 5-line change to make the string in the OP work correctly.

[nekevss]

I've been looking at this. I think I'm still confused about the wording on the base issue above.

From what I understand, "2000-01-01T00:00Z[Etc/GMT]" should work with try_from_str, but then the same string should fail with the try_lenient_from_str, at least according to current behavior.

My general thoughts are:

If it is not working with try_from_str, then yes that should definitely be fixed, because that feels like a bug.

If it's not working with try_from_lenient_str due to the RequiresCalculation error, then I think it would be reasonable to have a check to exempt Etc/GMT and Etc/UTC from requiring calculation. My reasoning is mostly due to the special treatment of those identifiers in ECMA402's AvailableNamedTimeZoneIdentifiers() in step 5.c., which seems to align with the thought process already at play in Intermediate::lenient.

But again, I might be misunderstanding the issue above.

[sffc]

I realized that I think the problem is that we unconditionally treat Z as "requires calculation", even if the time zone is Etc/GMT or Etc/UTC. My proposal is to allow Z if the time zone is one of those fixed zones.

[nekevss]

Agreed. The method should be able to handle Etc/UTC, Etc/GMT, GMT, or UTC without returning the requires calculation error.