如何编写带时区但没有时间成分的ISO 8601日期 [英] How can I write an ISO 8601 date with a timezone but no time component
问题描述
具有时区的
指向该日历上的任何给定日期都不会告诉我有关时区的任何信息.我可以将日历提供给其他时区的人，他们仍然可以谈论日期.简而言之，如果我们两个人都同时指向今天"，那么我们可能不会指向同一日期.因此，时区仅在我们应用时间上下文时才适用，无论是现在"还是特定的时间上下文.
但是，我们确实倾向于根据时区对给定日期的所有时间点进行合理化处理.在您的示例中，为"UTC日".我们的意思是它从一天的 T00:00Z 到下一天的 T00:00Z 之前运行.这通常是 xs:date 之类的允许时区偏移的原因.
如果我们要严格遵守ISO 8601并表示相同的含义，则必须提供一系列日期和时间值，在ISO 8601规范的4.4节中将其称为时间间隔"，并且用正斜杠(/)字符分隔.这样的值的一个示例是 2018-09-07T00:00Z/2018-09-08T00:00Z .但是，请务必小心，因为ISO 8601不会对结束日期进行整体解释还是完全解释.此处有更多信息.
间隔的另一个ISO 8601表示形式允许开始时间和持续时间组件，例如 2018-09-07T00:00Z/P1D .在我看来，这似乎是最接近ISO 8601的完全表示方式，以UTC表示的整个日期.
还是个人而言，如果我需要传达带日期的时区，即使不严格遵守，我仍将使用 2018-09-07Z .只要确保您所有数据的使用者都同意这种格式即可.如果您无法执行此操作，只需传递 2018-09-07 并为您的字段命名，例如 utcDate .
An ISO 8601 datetime with a timezone is formatted like this:
2018-09-07T05:28:42Z
However, I need to represent some dates in my system where the precision is days, not seconds, which means that it would be an ISO 8601 calendar date. Calendar dates are formatted like this:
2018-09-07
In the Wikipedia article about the standard (I don't have access to the standard itself, as you have to pay for that privilege), there is no mention of timezone when discussing dates. It does talk about omitting parts of the time:
Either the seconds, or the minutes and seconds, may be omitted from the basic or extended time formats for greater brevity but decreased accuracy: [hh]:[mm], [hh][mm] and [hh] are the resulting reduced accuracy time formats.
From this, it seems that you cannot omit hours, so I could not write a calendar date like this:
2018-09-07TZ
It appears that the best I can do is truncating down to the hour:
2018-09-07T00Z
I don't want to do this if I can avoid it, however, as I am adding more precision to a date than is really there. The date means "sometime during the day of 07 September, 2018 in the UTC timezone", not "sometime during the midnight hour of 07 September, 2018 in the UTC timezone".
Any suggestions?
Officially, the ISO 8601 spec does not allow for a date with a time zone unless a time is provided. Thus, if you wish to remain ISO 8601 compliant, you cannot provide additional information for date-only values than year, month, and day (without resorting to time intervals - mentioned further below).
One format that does allow for this is XML Schema (aka "XSD"), in the xs:date type. There, it is optional, and would immediately follow the day, such as 2018-09-07Z. The XSD spec calls out in Section D.3 Deviations from ISO 8601 Formats:
D.3.4 Time zone permitted
The lexical representations for the datatypes date, gYearMonth, gMonthDay, gDay, gMonth and gYear permit an optional trailing time zone specificiation.
I realize you weren't asking about XSD, but this the only normative reference I'm aware of that's freely available online that calls out the time zone on a date is a deviation from ISO 8601.
As others have pointed out - thinking about a date with a time zone is a tricky thing. In many aspects, a date-only value is ambiguous. Consider if I presented you a calendar such as this one:
Pointing at any given date on this calendar doesn't tell me anything about time zones. I can give the calendar to someone in a different time zone and they will still be able to talk about dates. It's simply that if we both point at "today" simultaneously, we might not be pointing at the same date. Thus, time zones only apply when we apply a time context, whether "now" or a specific one.
However, we do tend to rationalize about all points in time on a given day in terms of a time zone. In your example, the "UTC Day". We mean that it runs from T00:00Z of one day, to just before T00:00Z of the next. This is generally the reasoning behind things like xs:date allowing a time zone offset.
If we wanted to be strictly ISO 8601 compliant and represent the same meaning, we'd have to provide a range of date+time values, which are called "time intervals" in section 4.4 of the ISO 8601 spec, and are separated with a forward slash (/) character. An example of such a value would be 2018-09-07T00:00Z/2018-09-08T00:00Z. However, be careful because ISO 8601 says nothing about whether the end date should be interpreted inclusively or exclusively. More on that here.
Another ISO 8601 representation of an interval allows for a start time and a duration component, such as 2018-09-07T00:00Z/P1D. This feels to me like the closest fully ISO 8601 compliant way to represent a whole date interpreted in UTC.
Still, personally, if I needed to convey time zone with a date, I would use 2018-09-07Z even if it wasn't strictly compliant. Just make sure all consumers of your data agree on this format. If you can't do that, just pass 2018-09-07 and name your field something like utcDate.
这篇关于如何编写带时区但没有时间成分的ISO 8601日期的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
