From 403511f52a079072a7b78085342cb6eaf3651961 Mon Sep 17 00:00:00 2001 From: Steve Lhomme Date: Mon, 26 Jul 2021 08:14:48 +0200 Subject: [PATCH] Use a more vague range as it's informational --- specification.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specification.markdown b/specification.markdown index e613605..1b5269f 100644 --- a/specification.markdown +++ b/specification.markdown @@ -448,7 +448,7 @@ A UTF-8 Element contains only a valid Unicode string as defined in [@!RFC3629], A Date Element **MUST** declare a length of either zero octets or eight octets. If the EBML Element is not defined to have a default value, then a Date Element with a zero-octet length represents a timestamp of 2001-01-01T00:00:00.000000000 UTC [@!RFC3339]. The Date Element stores an integer in the same format as the Signed Integer Element that expresses a point in time referenced in nanoseconds from the precise beginning of the third millennium of the Gregorian Calendar in Coordinated Universal Time (also known as 2001-01-01T00:00:00.000000000 UTC). -This provides a possible expression of time from 1708-09-22T00:12:43.145224192 UTC to 2293-04-11T23:47:16.854775807 UTC. +This provides a possible expression of time from September 1708 to April 2293. The integer stored represents the number of nanoseconds between the date to express and 2001-01-01T00:00:00.000000000 UTC, not counting leap seconds. That is 86,400,000,000,000 nanoseconds for each day. Conversions from other date systems should ensure leap seconds are not counted in EBML values.