Whitespaces inside the quotation changes the behavior of `TZ="TIMEZONE"`

[Davoodeh]

This was a minor comment on #232 (comment) and it was suggested to create a separate issue for it

The following is the original copied here:

---

Hello, thanks to everybody for the great work.

I was studying this PR for a while and I was wondering that is there any reason (beyond performance) on why TZ="VALUE" is not relaxed with inner optional whitespaces (i.e TZ=" VALUE ")? Since such change passes all the current tests, this is a bit confusing to me.

This changes some behavior in an example like the following:

// prefixed whitespace
test(r#"TZ=" UTC-5:20:15""#, fixed_offset(0)); // current
test(r#"TZ=" UTC-5:20:15""#, fixed_offset(19215)); // with relaxed conditions

// prefixed whitespace
test(r#"TZ="UTC-5:20:15 ""#, Err(Backtrack(ContextError { context: [], cause: None }))); // current
test(r#"TZ="UTC-5:20:15 ""#, fixed_offset(19215)); // with relaxed conditions

Naturally, this can be generalized to the cases with :.

Whitespace relaxation can further improve in an unrelated example like: parse_datetime(" TZ=\"...\""). However in parse_datetime example, the user can easily just trim the input while removing the inner spaces of the quotation of this case is not as simple so that's why I think it's a quality improvement (if it is justified to begin with).

Example of changes that will relax this limitation:

diff --git a/src/items/timezone.rs b/src/items/timezone.rs
index 0414ee8..0009d17 100644
--- a/src/items/timezone.rs
+++ b/src/items/timezone.rs
@@ -16,6 +16,7 @@

 use jiff::tz::{Offset, TimeZone};
 use winnow::{
+    ascii::space0,
     combinator::{alt, delimited, opt, preceded, repeat},
     stream::AsChar,
     token::{one_of, take_while},
@@ -25,7 +26,12 @@ use winnow::{
 use super::primitive::{dec_uint, plus_or_minus};

 pub(super) fn parse(input: &mut &str) -> ModalResult<TimeZone> {
-    delimited("TZ=\"", preceded(opt(':'), alt((posix, iana))), '"').parse_next(input)
+    delimited(
+        ("TZ=\"", space0),
+        preceded(opt((':', space0)), alt((posix, iana))),
+        (space0, "\""),
+    )
+    .parse_next(input)
 }

 /// Parse a posix (proleptic) timezone string (e.g., "UTC7", "JST-9").

[Davoodeh]

In #232 (comment) it became clear that this is to mimic GNU date.

To answer that: I was aware of this behavior in the GNU parser but always thought this was simply an edge case that nobody ever addressed. A mere side-effect/bug of their implementation. I argue that for two thoughts on the back of my head:

1. I doubt if this is a behavior that users rely on.
2. It does not seem that drastic shift is intentional looking at the strings.

At the end, I agree with #232 (comment):

maybe it is something that GNU could improve

But if you want to stick with the GNU behavior, I understand your vision.

Regardless, that technically answers my original question so feel free to close the issue if you see fit. However, if the goal is to mimic that behavior, consider removing the case where a ContextError is thrown (test(r#"TZ="UTC-5:20:15 ""#, Err(Backtrack(ContextError { context: [], cause: None })));).