Whitespaces inside the quotation changes the behavior of `TZ="TIMEZONE"`
まだ誰も着手していません。
評価
調査の方向性
src/items/timezone.rs から始め、既存の TZ="..." パーサーと現在のテストを確認してください。issue に記載されている空白のケースを確認し、他の無関係なタイムゾーン形式を変更せずに、パーサーが提案された内部空白の動作を受け入れることを検証してください。完了とは、意図したオフセットで関連するテストがパスすることです。
索引モデルが issue の本文から書いたものです。
説明
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").
- 主要言語
- Rust
- スター
- 37
- フォーク
- 44
- 平均マージ
- 2日 15時間
- マージ済み PR（30日）
- 8
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
uutils/parse_datetime のほかの issue
-
date input: unrecognized trailing tokens rejected (e.g. `8j`, `8 j`)再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープンbug good first issue
難易度 3/5 1〜2日 初心者へのやさしさ 65/100
uutils/parse_datetime#279 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 52/100
uutils/parse_datetime#160 · コメント 10 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 35/100
uutils/parse_datetime#82 ·
-
Cargo test fails at 0:20 JST再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープン
難易度 3/5 1〜2日 初心者へのやさしさ 35/100
uutils/parse_datetime#36 · コメント 4 件 · リアクション 1 件 ·
-
Dependency Dashboardオープン
難易度 4/5 3〜5日 初心者へのやさしさ 20/100
uutils/parse_datetime#9 ·
uutils/parse_datetime の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
NuSkooler/enigma-bbs#907 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
EasyTier/EasyTier#2672 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
bug good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
repowise-dev/repowise#3374 ·
メンテナーはふだん 1 日以内に返信