From 25f4df9287e8a81ddb710cd8a47b0ef210113d09 Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Sun, 4 Aug 2024 15:30:29 -0400 Subject: [PATCH] Move Representing Time section to Advanced Concepts section. --- index.html | 193 +++++++++++++++++++++++++++-------------------------- 1 file changed, 98 insertions(+), 95 deletions(-) diff --git a/index.html b/index.html index d367bf494..34f81d3f3 100644 --- a/index.html +++ b/index.html @@ -1970,101 +1970,6 @@

Validity Period

valid from the time the `verifiable credential` was created.

-

Representing Time

- -

-Implementers are urged to understand that representing and processing time -values is not as straight-forward as it might seem and have a variety of -idiosyncrasies that are not immediately obvious nor uniformly observed in -different regions of the world. For example: -

- - - -

-These are just a few examples that illustrate that the actual time of day, as -would be seen on a clock on the wall, can exist in one region but not exist in -another region. For this reason, implementers are urged to use time values -that are more universal, such as values anchored to the `Z` time zone over -values that are affected by Daylight Saving/Summer Time. -

- -

-This specification attempts to increase the number of universally recognized -combinations of dates and times, and reduce the potential for -misinterpretation of time values, by utilizing the -`dateTimeStamp` construction first established by the [XMLSCHEMA11-2] specification. In -order to reduce misinterpretations between different time zones, all time values -expressed in [=conforming documents=] SHOULD be specified in `dateTimeStamp` -format, either in Universal Coordinated Time (UTC), denoted by a `Z` at the end -of the value, or with a time zone offset relative to UTC. Time values that are -incorrectly serialized without an offset MUST be interpreted as UTC. Examples of -valid time zone offsets relative to UTC include `Z`, `+01:00`, `-08:00`, and -`+14:00`. See the regular expression at the end of this section for a formal -definition of all acceptable values. -

- -

-Time zone definitions are occasionally changed by their governing body. When -replacing or issuing new [=verifiable credentials=], implementers are advised -to ensure that changes to local time zone rules do not result in unexpected gaps -in validity. For example, consider the zone `America/Los_Angeles`, which has -a raw offset of UTC-8 and had voted to stop observing daylight savings time in -the year 2024. A given [=verifiable credential=] that had a `validUtil` -value of `2024-07-12T12:00:00-07:00`, might be re-issued to have a -`validFrom` value of `2024-07-12T12:00:00-08:00`, which would create a gap of -an hour where the [=verifiable credential=] would not be valid. -

- -

-Implementers that desire to check `dateTimeStamp` values for validity -can use the regular expression provided below, which is reproduced from the [XMLSCHEMA11-2] specification for -convenience. To avoid doubt, the regular expression in [[XMLSCHEMA11-2]] is the -normative definition. Implementers are advised that not all -`dateTimeStamp` values that pass the regular expression below are -valid moments in time. For example, the regular expression below allows for 31 -days in every month, which allows for leap years, and leap seconds, as well as -days in places where they do not exist. That said, modern system libraries that -generate `dateTimeStamp` values are often error-free in their -generation of valid `dateTimeStamp` values. The regular -expression shown below (minus the whitespace included here for readability), -is often adequate when processing library-generated dates and times on -modern systems. -

- - 
--?([1-9][0-9]{3,}|0[0-9]{3})
--(0[1-9]|1[0-2])
--(0[1-9]|[12][0-9]|3[01])
-T(([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?|(24:00:00(\.0+)?))
-(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))
-
-
@@ -3800,6 +3705,104 @@

Zero-Knowledge Proofs

+
+

Representing Time

+ +

+Implementers are urged to understand that representing and processing time +values is not as straight-forward as it might seem and have a variety of +idiosyncrasies that are not immediately obvious nor uniformly observed in +different regions of the world. For example: +

+ + + +

+These are just a few examples that illustrate that the actual time of day, as +would be seen on a clock on the wall, can exist in one region but not exist in +another region. For this reason, implementers are urged to use time values +that are more universal, such as values anchored to the `Z` time zone over +values that are affected by Daylight Saving/Summer Time. +

+ +

+This specification attempts to increase the number of universally recognized +combinations of dates and times, and reduce the potential for +misinterpretation of time values, by utilizing the +`dateTimeStamp` construction first established by the [XMLSCHEMA11-2] specification. In +order to reduce misinterpretations between different time zones, all time values +expressed in [=conforming documents=] SHOULD be specified in `dateTimeStamp` +format, either in Universal Coordinated Time (UTC), denoted by a `Z` at the end +of the value, or with a time zone offset relative to UTC. Time values that are +incorrectly serialized without an offset MUST be interpreted as UTC. Examples of +valid time zone offsets relative to UTC include `Z`, `+01:00`, `-08:00`, and +`+14:00`. See the regular expression at the end of this section for a formal +definition of all acceptable values. +

+ +

+Time zone definitions are occasionally changed by their governing body. When +replacing or issuing new [=verifiable credentials=], implementers are advised +to ensure that changes to local time zone rules do not result in unexpected gaps +in validity. For example, consider the zone `America/Los_Angeles`, which has +a raw offset of UTC-8 and had voted to stop observing daylight savings time in +the year 2024. A given [=verifiable credential=] that had a `validUtil` +value of `2024-07-12T12:00:00-07:00`, might be re-issued to have a +`validFrom` value of `2024-07-12T12:00:00-08:00`, which would create a gap of +an hour where the [=verifiable credential=] would not be valid. +

+ +

+Implementers that desire to check `dateTimeStamp` values for validity +can use the regular expression provided below, which is reproduced from the [XMLSCHEMA11-2] specification for +convenience. To avoid doubt, the regular expression in [[XMLSCHEMA11-2]] is the +normative definition. Implementers are advised that not all +`dateTimeStamp` values that pass the regular expression below are +valid moments in time. For example, the regular expression below allows for 31 +days in every month, which allows for leap years, and leap seconds, as well as +days in places where they do not exist. That said, modern system libraries that +generate `dateTimeStamp` values are often error-free in their +generation of valid `dateTimeStamp` values. The regular +expression shown below (minus the whitespace included here for readability), +is often adequate when processing library-generated dates and times on +modern systems. +

+ + 
+-?([1-9][0-9]{3,}|0[0-9]{3})
+-(0[1-9]|1[0-2])
+-(0[1-9]|[12][0-9]|3[01])
+T(([01][0-9]|2[0-3]):[0-5][0-9]:[0-5][0-9](\.[0-9]+)?|(24:00:00(\.0+)?))
+(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00))
+
+ +
+

Authorization