Date.new() ... DateTime.new() 是有效的语法吗？

Question

DateTime当我在序列运算符 ( ) 的两侧使用两个对象时...，Raku 报告说No such method 'succ' for invocant of type 'DateTime'. Did you mean any of these: 'sum', 'utc'?

DateTime.new("2022-03-26") ...  DateTime.new("2022-03-28")

然而，当运算符的左侧...是一个Date对象，右侧也是一个DateTime对象时，就会导致无限循环：

.say for Date.new("2022-03-26") ... DateTime.new("2022-03-28");
.say for Date.new("2022-03-26") ... DateTime.new("2022-03-18");

上述语法有效吗？是否应该报告错误？

作为比较，以下代码运行良好：

.say for Date.new("2022-03-26") .. DateTime.new("2022-03-28")
.say for Date.new("2022-03-26") .. Date.new("2022-03-28")

输出：

2022-03-26
2022-03-27
2022-03-28

Answer 1

无限循环

当operator左边...是一个Date对象，右边也是一个DateTime对象时，会导致死循环

是的。我认为这是潜在的错误：

say Date('2023-03-17') ~~ DateTime('2023-03-17') # False

假设一个...序列迭代，直到一个值（从 的左侧的起点/生成器生成...）智能匹配端点（在 的右侧...），然后从中缀切换~~到...当前可以保证无限循环。

我已经提出了问题。

..关于vs 的经验法则...

对于增量 1 语义，从起始值到结束值，我建议默认使用范围运算符 ( ..) 来创建Range. 如果您进行迭代，则当递增的 LHS 比较大于端点 RHS 时，生成的序列结束。假设 RHS 不是( Inf或*)，则如果在跨越从起点到终点的间隙之前有太多步骤，则范围只能“无限循环”（实际上只是花费太长的时间）。

...仅当您需要除递增 1 语义之外的其他内容时才使用序列运算符 ( )。

No such method 'succ'（aDateTime是时间戳）

ADateTime是时间，而不是日期。（它也许应该被命名为Timestamp，我可以想象它可能会被重命名为下一个十年，但我们现在有更大的鱼要炸。）引用该文档：

用于处理民用时间中的点...存储年、月、日、小时、分钟（全部Int）、秒（可能是小数）和时区。

因此，如果将a 放在范围 ( ) 或序列 ( )的左侧确实有效，即如果有s的方法，那么它大概应该以某个时间单位为步长——大概是一秒，分钟，或小时。（我想这就是为什么没有。会是哪一个？）DateTime......succDateTimesucc

也许这两条经验法则是合适的：

1. 如果您真正的意思是不考虑时区的日期，那么使用Date，不要使用DateTime。

2. 如果您真正的意思是某个时区内的日期，那么请考虑使用 aDateTime但确保明确指定时间部分。Date（这会让你很恼火，如果这就是你真正的意思，你就会使用它。）

话又说回来，DateTime如果您要单步执行或比较某些范围/序列，则使用 a 可能仍然不够，因为民用时间和时区本身就是一个复杂的事物，并且秒并不总是匹配：

1972年，引入了闰秒系统……那时，UTC时钟已经落后TAI 10秒，TAI于1958年与UT1同步，但从那时起一直在计算真正的SI秒。...它们在任何时间的显示之间的差异是 10 秒加上截至该时间已应用于 UTC 的闰秒总数；截至 2020 年 6 月，UTC 已应用 27 个闰秒...

（不，我不会解释 UTC、TAI、UT1、SI 和闰秒。）

换句话说，考虑使用或转换为Instants，特别是如果您希望使用..或...运算符，但不要忘记考虑闰秒。

（我认为你可以放心地忽略民用时间（这是约定的时间）和实际时间的流逝之间的差异，根据当前的物理定律/理论，这最终是绝对精确不可知的，假设你在我们之后没有读到这篇文章已经达到了宇宙的热寂。）