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

[Balázs Lengyel <[e-mail]>]

Thank you. I am happy with the answers. Balazs

-----Original Message-----
From: Juergen Schoenwaelder <[e-mail]> 
Sent: 2020. március 22., vasárnap 22:12
To: Balázs Lengyel <[e-mail]>
Cc: '[e-mail]' <[e-mail]>
Subject: Re: [netmod] Simple date in 6991bis-02

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/>