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

Open
#240 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
45/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Stale
Tech stack
rust
Domain
backend

Research direction

Start in src/items/timezone.rs and review the existing TZ="..." parser and its current tests. Check the whitespace cases described in the issue, then verify that the parser accepts the proposed inner whitespace behavior without changing unrelated timezone forms; done means the relevant tests pass with the intended offsets.

Written by the indexing model from the issue text.

Description

This was a minor comment on https://github.com/uutils/parse_datetime/pull/232#issuecomment-3421283917 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").
Dominant language
Rust
Stars
37
Forks
39
Avg merge
17h 48m
Merged PRs (30d)
8

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from uutils/parse_datetime

All issues in uutils/parse_datetime

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.