在我的页面上,用户输入生日。该模型将日期保存为 javascript 日期。在请求中,日期将转换为 UTC,并带有给定日期的时区偏移。在服务器端, Jersey 读取该日期并添加当前时区偏移。
所以在写这篇文章时发生了什么(服务器处于 CET):
用户输入:
01/03/1967
客户转账:
JSON.stringify(new Date(1967,2,1))
"1967-02-28T23:00:00.000Z"
服务器增加一小时,并正确01/03/1967
。
但是如果用户输入
01/04/1967
客户转账:
JSON.stringify(new Date(1967,3,1))
"1967-03-31T22:00:00.000Z"
服务器增加一小时,并错误地获取31/03/1967
。当夏天涉及夏令时时,服务器可能会增加两个小时,日期又正确了。
我现在仅传输日期字符串(不是日期对象,而是用户输入的内容)。
其他人也有这个问题吗?如何解决这个差异?
我没有从 JSON.stringify 中得到任何确定性行为,为什么它有时使用 2 小时偏移,为什么有时只使用一小时。
例如,请参阅以下日期:
JSON.stringify(new Date(1981,5,1))
""1981-05-31T22:00:00.000Z""
JSON.stringify(new Date(1980,5,1))
""1980-05-31T23:00:00.000Z""
最佳答案
您选择了错误的模型来处理您的输入。基本上你从一个简单的日期开始(没有时间和时区)。所以你应该保留这个结构。这意味着将输入转换为 JavaScript 日期(包括时间和时区)实际上并不好,因为这会引入您观察到的问题。
不幸的是,JavaScript 的内置版本不提供简单的日期作为数据类型。 但你至少可以将用户输入转换为ISO-8601格式的字符串,即:yyyy-MM-dd
然后你通过 JSON 发送这个字符串,在服务器端你可以将其解析为你想要的任何类型(这里我再次建议使用普通日期作为模型,如 Java 8 中的 java.time.LocalDate
或 org.joda.time.LocalDate
或类似的模型)。但即使您选择 java.util.GregorianCalendar ,您的时区问题也应该消失,因为日期不会更改,而只会补充服务器的(不必要的)时间和时区信息。
注意:如果 Jersey 仍然需要由 JSON 生成的完整日期时区输入,那么您可以尝试手动将合适的时间部分(例如午夜)和合适的时区部分添加到用作 JSON 输入的字符串中。
关于java - 使用 Jersey 读取时区和 JSON,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/22607361/