Re: [netmod] Simple date in 6991bis-02

[Juergen Schoenwaelder <[e-mail]>]

On Thu, Mar 19, 2020 at 11:30:17AM +0000, Balázs Lengyel wrote:
> Hello,
> 
> This might have been discussed earlier, but I still find it strange that the
> 
> 
>    typedef date {
> 
> has the timezone as a mandatory part. While I understand the issue that when
> a day starts/ends is uncertain without the timezone, in real life people
> practically never add the timezone to a date, and it does not cause major
> problems. So IMHO following life we should have a simple-date datatype that
> does not include any timezone. Actually we do have that datatype just we
> called it revision-identifier. Really strange.
>

I checked RFC 3339 again and it defines full-date without a timezone.
On the other hand, XML schema's definition of date seems to have an
optional timezone offset. I think following XML schema by making the
timezone offset optional is the right approach.

It might also be usefult to define time as a typedef. RFC 3339 defines
full-time with a mandatory timezone while XML schema defines time with
optional timezone. Again, I would follow XML schema here, making the
timezone offset optional for the time type as well.

> I would also consider to tighten up the pattern for
> revision-identifier/date/date-and-time.
> 
>         pattern '\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1])';
> 
> This would prohibit  2020-16-67 : months > 12 or days > 31

If we tighten the pattern, we should do this for date, date-and-time,
and revision. And then we should also tighten the revision offset,
which currently is \d{2}:\d{2}. And here things get interesting again.
RFC 3339 restricts the offset to 00-23 (hour) and 00-59 (minute). XML
schema says the hour is in 00-14 and the minute in 00-59. The spec says:

  Based on timezones currently in use, (c) could vary from
  2000-01-20T12:00:00+12:00 to 2000-01-20T12:00:00-13:00. It is,
  however, possible for this range to expand or contract in the
  future, based on local laws. Because of this, the following
  definition uses a somewhat broader range of indeterminate values:
  +14:00..-14:00.

Perhaps we should follow that approach. This would mean we have:

  typedef date {
    type string {
      pattern '\d{4}-(1[0-2]|0[1-9])-(0[1-9]|[1|2][0-9]|3[0-1])';
            + '(Z|[\+\-]((1[0-3]|0[0-9]):([0-5][0-9])|14:00))?';
    }
  }

Looking at the description and RFC 3339 again, I noticed a real
problem or bug in our definition: RFC 6991 says:

      [...] The canonical format for
      date values with an unknown time zone (usually referring
      to the notion of local time) uses the time-offset -00:00.

This is not consistent with what RFC 3339 says in section 4.3:

   If the time in UTC is known, but the offset to local time is unknown,
   this can be represented with an offset of "-00:00".

RFC 3339 seems to be silent about the situation where neither the
offset to UTC is unknown and I strongly dislike that the two specs
differ in the definition of the -00:00 semantics. I would call this a
bug and fix it but then others may claim this is an non-backwards
compatible change...

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>