问题标签 [rust-chrono]

虽然chrono支持以 ISO 8601 兼容格式解析日期、时间和时区，但我无法在 crate 中找到任何方法来解析持续时间字符串，例如PT2M表示 2 分钟的字符串。

免责声明：我是 Rust 的新手（以前的经验是 Python、TypeScript 和 Go，按顺序排列），我完全有可能遗漏了一些非常明显的东西。

我正在尝试构建一个 Rust 时钟接口。我的基本目标是我有一个报告实际时间的小时钟结构，以及一个报告伪造版本以供测试的存根版本。请注意，这些是历史测试而不是单元测试：我的目标是重放历史数据。我认为问题的一部分也可能是我理解chrono得不够好。这显然是一个很棒的库，但是我在 和 中的类型与实例关系方面遇到了chrono麻烦chrono_tz。

无论如何，这就是我所拥有的：

我的最终目标是让其他结构dyn Clock在特定时区有一个。该时钟可能是系统时钟（具有适当的时区转换），也可能是某种存根。

这是我对系统时钟 shim 的尝试，但一切都出现了可怕的错误：

关键问题是Utc::now().with_timezone(&Tz)。编译器需要一个值，而不是一个类型。很公平，除了chrono似乎chrono_tz没有时区值。我一直在寻找正确的东西放在这里，似乎没有什么是正确的答案。

嗨，Stack Overflow 的 Rustaceans，我正在继续我在 Rust 中的新项目，但我仍然遇到了我一直在尝试构建的全天候特性。作为参考，我选择了第二种解决方案（向我推荐的那个）。

我现在面临的挑战是，我发现指定通用时区的需要正在“渗透”到其他结构中。本质上，如果任何结构需要包含时钟（或任何其他包含时钟的结构），则该结构也需要泛型，即使这些结构与时间或时区关系不大。

我最终想要达到一个点，我可以将时区存储为某物的属性，并能够拥有一个返回DateTime该时区对象的方法：

我无法正常工作的部分是DateTime<??>部分，因为在编译时不一定知道时区。解决这个问题的正确方法是什么？看起来我可以做到Box<dyn impl Datelike + Timelike>，但在我天真的理解看来，这似乎是高开销？对于想要针对我的函数编写代码的人来说，这似乎是很多工作。

我应该提到我是 Rust 的新手，我完全有可能误解了一些基本的东西，但是我查看了文档以试图更好地理解并且没有找到我想要的东西。

更新

经过更多的迭代，我有一个状态，我总是要求时区作为参数：

这似乎仍然不如将时区作为我的时钟的属性，因为我希望时钟始终在单个时区运行，尽管有无可争辩的优势。

但是，这会产生一个新问题，即 nowClock不是“对象安全”特征，因为TimeZone它似乎具有Sized超特征。:-(

我正在尝试chrono::NaiveDate用作数据库模型字段。这是模型：

当我运行时cargo check，我从 rustc 收到以下错误：

我的相关行Cargo.toml：

运行cargo tree | grep chrono给出以下输出，表明与 没有版本冲突chrono：

我以前在柴油模型中使用过，并且在导出宏NaiveDate时没有问题。Insertable我在这里遗漏了什么阻止宏在它似乎被实现的情况下diesel::Expression实现？chono::NaiveDatechono::NaiveDateTime