我正在使用一个API，它根据一组配置的参数生成时间段。
例如，我可以指定我希望在1月1日午夜开始的12个月期间，因此API将生成12个月的期间
LIO现在API期望为句点序列提供的开始日期参数是UTC格式的ISO格式字符串。所以我目前在英国，因此，如果我选择从2016年1月1日开始每月一次，这将是01 Jan 2016 00:00:00 – 31 Jan 2016 23:59:59
01 Feb 2016 00:00:00 – 28 Feb 2016 23:59:59
Through to
01 Dec 2016 00:00:00 – 31 Dec 2016 23:59:59
，这是我提供的API调用，我正在说我的第一个实例月度期应该开始。
现在，如果我通过API查看生成的每月期间的开始和结束日期，我会看到它们回来了
2016-01-01T00:00:00Z有些事情让我对这些生成的时期感到震惊，那就是我希望它们在午夜时开始我现在的位置，但是受GMT日光时间影响的时期，所以说我的四月时期在生成期间会是这样的来自API
2016-01-01T00:00:00Z - 2016-01-31T23:59:59Z
2016-02-01T00:00:00Z - 2016-02-28T23:59:59Z
Etc to
2016-12-01T00:00:00Z - 2016-12-31T23:59:59Z
将上述开始日期解析为日期对象以便在客户端（在我的机器上）查看将显示为
2016-04-01T00:00:00Z - 2016-04-30T23:59:59Z
所以它说这个时期是凌晨1点而不是午夜。 现在说，如果我希望从夏令时生效的6月1日起生成12个月。
我的客户端代码目前将为Fri Apr 01 2016 01:00:00 GMT+0100 (GMT Daylight Time)
的API提供开始日期。这会导致API将每个月的生成日期生成为
2016-05-31T23:00:00Z但是现在对于一段时间不在格林尼治标准时间日光时间，所以Jan例如它将显示为
2016-05-31T23:00:00Z - 2016-06-31T22:59:59Z (June Period)
2016-06-31T23:00:00Z - 2016-07-31T22:59:59Z (July)
Etc to
2017-04-30T23:00:00Z - 2017-05-31T22:59:59Z (May)
意味着我的客户会将开始日期视为
2016-12-31T23:00:00Z - 2017-01-31T22:59:59Z
所以不是1月1日00:00
这是否表明API应该知道用户时区，因此API中的句点生成逻辑可以在计算开始日期和结束日期时将其计算在内？
也许我在这里思考问题？！
答案 0 :(得分：0)
我在这里看到的唯一真正的问题是：
这是否表明API应该知道用户时区，因此API中的句点生成逻辑可以在计算开始日期和结束日期时将其计算在内？
一般来说，答案是是。每当您将日历日期映射回特定时刻时，根据定义，您必须涉及时区。该时区可以是用户的时区，也可以是某个特定的业务位置，或固定为UTC，但它们确实是逻辑的一部分。
请注意，并非每个日历日期在每个时区都有有效的本地“午夜”。一个例子是2015-10-18在巴西圣保罗，那天的第一个时刻是凌晨1点，因为他们的春季前进夏令时转换。世界上还有很多其他的例子。
完全避免问题的唯一方法是不在特定时间处理。如果您只处理整个日期，那么您的代码当然可以计算每个月的确切日期，而无需了解任何时区。 2016-01-01到2016-01-31无法了解时间或时区。只有在您尝试询问当前日期是什么时，或者现在是否在该范围内，或者是否有其他特定即时时在这个范围内你必须开始考虑时区。