Whitespaces inside the quotation changes the behavior of `TZ="TIMEZONE"`
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
从 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
- 平均合并
- 3 天 13 小时
- 30 天内合并 PR
- 10
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
uutils/parse_datetime 的其他 Issue
-
date input: unrecognized trailing tokens rejected (e.g. `8j`, `8 j`)可能重新可做 关联的 PR 已关闭且未合并。 未关闭bug good first issue
难度 3/5 1-2 天 新手友好度 65/100
uutils/parse_datetime#279 · 3 条评论 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 52/100
uutils/parse_datetime#160 · 10 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 35/100
uutils/parse_datetime#82 ·
维护者通常 1 天内回复
-
Cargo test fails at 0:20 JST可能重新可做 关联的 PR 已关闭且未合并。 未关闭
难度 3/5 1-2 天 新手友好度 35/100
uutils/parse_datetime#36 · 5 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 20/100
uutils/parse_datetime#9 ·
维护者通常 1 天内回复
查看 uutils/parse_datetime 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
project-robius/robrix#1154 ·
维护者通常 1 天内回复
-
Add Mimir未关闭
难度 1/5 1 小时以内 新手友好度 78/100
slavakurilyak/awesome-ai-agents#759 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 62/100
compiler-explorer/compiler-explorer#9272 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 63/100
pop-os/cosmic-files#2117 ·
维护者通常 2 天内回复