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

From: Balázs Lengyel <[email-masked]>
Date: Thu, 19 Mar 2020 11:30:17 +0000

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

Regards Balazs

-- 

Balazs Lengyel                    Senior Specialist
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909              email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 22 Mar 2020 22:12:28 +0100

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

> 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: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Balázs Lengyel <[email-masked]>
Date: Mon, 23 Mar 2020 08:07:05 +0000

Thank you. I am happy with the answers. Balazs

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

On Thu, Mar 19, 2020 at 11:30:17AM +0000, Balázs Lengyel wrote:
> 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.

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

  typedef date {
    type string {

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

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