这是一个非常小的问题，但当我今天（5 月 28 日）创建新的邀请链接时，UI 中提供的偏移日期与标签不匹配，例如：
我之所以注意到这一点，是因为链接比我预期的要早超时，而且我认为“下个月”选项实际上会选择 6 月 1 日作为偏移日期，而不是 6 月 28 日。
1 个赞
抱歉，我不太明白您的帖子？截图中的内容在我看来是正确的？您能否更详细地说明您认为哪里有问题？
2 个赞
从5月28日起两个月并不是7月1日。
1 个赞
没错，但意图是“当我们从一个月过渡到下一个月时”。下个月确实是从6月1日开始，对吗？再下一个月则是从7月1日开始，对吗？
“您的邀请有效期至本月底”更容易解释，也更准确地表达了本意，相比之下，“您的邀请会在月中某个完全随机的日期过期”则不够恰当。
4 个赞
这对我来说很有道理。我在书签定时器上遇到过相反的问题。对于定时书签，当选择“下周”选项时，日期会被设置为未来 7 天，但我对“下周”的理解是下一周的周一。我不确定哪种设定未来日期的方法最好，但在整个用户界面中采用一致的方法可能值得考虑。
4 个赞
没错！虽然这不属于该讨论范围，但我每次都会对此感到困惑！
1 个赞
是的，我认为我们在开发这个功能时，有些内容在翻译中丢失了 @martin。或许你可以调整一下日期，以更准确地反映上述意图？
当崭新闪亮的一周/一个月开始时提醒我！
这才是我们的本意，而不是“从今天起整整 7 天后告诉我”或“从今天起整整 30 天后告诉我”。
4 个赞
我们有一个专门的“周一”选项来实现这一点：
如果“下周”的意思是“下周的开始”，那我们就不需要“周一”这个选项了。
这确实令人困惑，因为我们之前讨论过这个问题，并且有一个进行中的 PR，旨在使邀请和其他未来日期输入与书签和主题计时器的行为保持一致：FEATURE: make future-date-input consistent with other components and customizable by AndrewPrigorshnev · Pull Request #12985 · discourse/discourse · GitHub
那么，我们是否希望统一规定，所有涉及“周”和“月”级别的选项都应表示“下周初”、“两周后的周初”以及“下月初”？据我所知，月份选项已经遵循这种行为，只是周选项尚未如此。如果是这样，我们还需要从书签中移除“周一”选项，因为它将变得不再相关。
“两个月”的措辞让我感觉是“现在 + 两个月”，而不是“两个月后那个月的月初”，所以我认为我们也需要调整这一点。@andrei 一直在负责这个进行中的 PR，也许他可以来处理这个问题？
3 个赞
你需要回顾最初的设计意图，也就是 Google GMail 的做法：
我认为我们在某个阶段逐渐偏离了目标，但你可以看出，这非常侧重于“下一个时间区间”的概念，具体包括：
- 下一个工作日开始时（即明天）
- 接下来的一周中间
- 周末开始时
- 下一周开始时
这始终是我的初衷，我也曾尽量清晰地表达这一点。但我觉得我们可能像玩“传话游戏”一样，信息在传递过程中被误传或混淆了。以下是我 2019 年 11 月发布的原始帖子：
请注意，重点依然一致：
- 当天晚些时候（基本上是指傍晚开始，或“工作日结束”时）
- 下一个工作日开始时（即明天）
- 下一周开始时
此外，你还可以设置任意时间，这当然没问题，但这从来不是该对话框的主要焦点。将任意时间作为额外选项包含进来是可以的，但“从当前日期起任意 5 天后”的实用性远不如“直到下一周开始”、“直到下个月开始”、“直到工作日结束、傍晚开始”、“直到下个月开始”、“直到周末开始”等表述直观和有用。
因此，回到邀请功能，其逻辑应当保持一致：
我认为我们在该功能上有些偏离方向，但经过一些调整应该可以恢复正常……所有必要的工具都已具备。
3 个赞
上述 
确实是所有提供的 Gmail 示例所表达的意图。当你说
明天提醒我这件事
下周提醒我这件事
下个月提醒我这件事
你的意思是
在下一个日期开始时提醒我这件事
在下一周开始时提醒我这件事
在下一个月份开始时提醒我这件事
而不是
在整整 24 小时后提醒我这件事
在整整 7 天后提醒我这件事
在整整 30 天后提醒我这件事（另外——并非所有月份的天数都相同！）
添加一个“从现在起任意 x 天”的选项作为补充功能完全没问题，但这并非最初的目标。因此，供参考 @martin 或 @andrei，无论最终由谁负责这项工作。我认为两者可以兼顾，并且始终会保留一个“任意日期”的选项，但核心思路是：人们主要依据“直到下一个主要日历事件”的时间间隔来思考——无论是新的一天、周末、新的一周，还是新的一个月。
4 个赞
顺便一提，现在这一切都讲得通了。不过我之所以提出这个问题，部分原因是我们曾达成一项内部政策，即邀请链接的有效期不得超过一个月。而分块的未来日期输入方式使得这一规定难以执行。我理解这个设计的初衷，但当用户处于月末时，第一个选项往往不太实用。
2 个赞
您始终可以处理任意日期以及日期偏移；没有任何功能会被_移除_。
3 个赞