Subject: Re: [VCARDDAV] Issue 236 (Suggestion for allowance of truncateddate format in BDAY)

From: Simon Perreault <[email-masked]>
Date: Tue, 28 Apr 2009 08:54:52 -0400

Sorry for taking so long to reply. Text will be present in -07 regarding this
issue, and it is inspired from this comment.

Javier Godoy wrote, on 04/11/08 02:25 AM:
> While RFC 2425 allows both basic (yyyymmdd) and extended (yyyy-mm-dd)
> formats, support for basic format was dropped in vcarddav-vcardrev-02.
> Are we moving now in the opposite direction? Based on previous
> discussion I will assume we are (if this were not settled yet, it should
> be a separate issue).

Only the basic format will be supported in -07. Rationale:

- The general consensus was that we should pick one format.
- Basic format has less characters.
- Some stuff in ISO 8601 is only expressible in basic format.

> Questions:
> 
> 1. Allow timezone for time / date-time values?

I don't think anyone suggested removing it, so I think we'll keep it.

> 2. Do we need different datatypes?

I think the usual three datatypes are good: date, time, date-time.

> 3. Are we going to specify rules like time-truncated, which are not used
> in vcard because no property allows time-only values?

I think we should. vCard is now extensible so we can imagine new properties
making use of this data type. In that case we should provide a good data type so
that people do not start writing almost-duplicate data types.

> *** BDAY and DDAY ***
> value = date-truncatable-reducible / (date-truncatable "T" time-reducible)

I think it should be simpler. The text says that the default type is date, and
it can be reset to a date-time. Let's make the example reflect the text with the
addition of a VALUE parameter:

          BDAY:19960415
          BDAY;VALUE=date-time:19531015T231000Z

(More on the rest of this comment later.)

> which allows:
>   a) complete date and date-time representations,
>   b) date and date-time representations with arbitrarly reduced precision,
>   c) date representations truncated to the month, and
>   d) date representations truncated to the day
> 
> 
> *** REV ***
> 
> In RFC 2426, REV was defined as a (complete) date-time, which "can also
> be reset to a single date value". Since the ABNF in draft version 5 is
> not complete, it is not clear if
> reduced precision may be applied to this property. It is not also clear
> if issue #236 is intended for BDAY/DDAY only, or for any dated property.
> 
> a)  value       = date-complete [ "T" time-complete ]
> which only allows complete representations (enough for a revision
> timestamp)
> 
> b)  value        = (date-complete "T" time-reducible) / date-reduceable
> which allows date and date-time representations with arbitrarly reduced
> precision (e.g. "REV:2008" and "REV:20081104T05"), but no truncation.
> 
> c) (just mentioned here for the sake of completeness) same as BDAY,
> which would allow --mmdd, among other values which are not useful as
> timestamps.

Nowadays, REV is generated by a machine, and is mostly used in the context of
synchronization. It really is a timestamp, a complete date and time. Therefore,
I created the timestamp value type and made REV use it.

Here's the proposed ABNF:

===========================================================================
year   = 4DIGIT  ; 0000-9999
month  = 2DIGIT  ; 01-12
day    = 2DIGIT  ; 01-28/29/30/31 depending on month and leap year
hour   = 2DIGIT  ; 00-23
minute = 2DIGIT  ; 00-59
second = 2DIGIT  ; 00-58/59/60 depending on leap second
zone   = "Z" / utc-offset

date          = year     month  day
              / year "-" month
              / "--"     month [day]
              / "--"      "-"   day
date-noreduc  = year     month  day
              / "--"     month  day
              / "--"      "-"   day
date-complete = year     month  day

time          = hour [minute [second]] [zone]
              /  "-"  minute [second]  [zone]
              /  "-"   "-"    second   [zone]
time-notrunc  = hour [minute [second]] [zone]
time-complete = hour  minute  second   [zone]

date-time = date-noreduc  "T" time-notrunc
timestamp = date-complete "T" time-complete

utc-offset = sign hour [minute]
===========================================================================

And here's the proposed text:

===========================================================================
5.3.  DATE, TIME, DATE-TIME, and TIMESTAMP

   "date", "time", "date-time", and "timestamp": Each of these value
   types is based on a the definitions in [ISO.8601.2004] standard.
   Multiple such values can be specified using the comma-separated
   notation.

   Only the basic format is supported.

5.3.1.  DATE

   A calendar date as specified in [ISO.8601.2004] section 4.1.2.

   Reduced accuracy, as specified in [ISO.8601.2004] sections 4.1.2.3 a)
   and b), but not c), is permitted.

   Expanded representation, as specified in [ISO.8601.2004] section
   4.1.4, is forbidden.

   Truncated representation, as specified in [ISO.8601.2000] sections
   5.2.1.3 d), e), and f), is permitted.

   Examples for "date":

             19850412
             1985-04
             1985
             --0412
             ---12

5.3.2.  TIME

   A time of day as specified in [ISO.8601.2004] section 4.2.

   Reduced accuracy, as specified in [ISO.8601.2004] section 4.2.2.3, is
   permitted.

   Representation with decimal fraction, as specified in [ISO.8601.2004]
   section 4.2.2.4, is forbidden.

   Midnight is always represented by 00, never 24 (see [ISO.8601.2004]
   section 4.2.3).

   Truncated representation, as specified in [ISO.8601.2000] sections
   5.3.1.4 a), b), and c), is permitted.

   Examples for "time":

             102200
             1022
             10
             -2200
             --00
             102200Z
             102200-0800

5.3.3.  DATE-TIME

   A date and time of day combination as specified in [ISO.8601.2004]
   section 4.3.

   Truncation of the date part, as specified in [ISO.8601.2000] section
   5.4.2 c), is permitted.

   Examples for "date-time":

             19961022T140000
             --1022T1400
             ---22T14

5.3.4.  TIMESTAMP

   A complete date and time of day combination as specified in
   [ISO.8601.2004] section 4.3.2.

   Examples for "timestamp":

             19961022T140000
             19961022T140000Z
             19961022T140000-05
             19961022T140000-0500
===========================================================================

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: "Javier Godoy" <[email-masked]>
Date: Wed, 29 Apr 2009 11:44:10 -0300

On Tue, 28 Apr 2009 08:54:52 -0400, Simon Perreault wrote:

> Sorry for taking so long to reply. Text will be present in -07 regarding
> this issue.

+1, with the following comment:

When the value type is date-time / date / time, the value parameter is 
redundant, and it should be possible to omit it.
This proposed modification would remove the requirement for specifying a VALUE 
parameter in BDAY, DDAY and any aniversary-like extension property.

One could understand a date value as a date-type value with date
precision, and a time value as a date-time value where the the date part is
truncated. Both conforms ISO 8601:2004 with the truncation feature borrowed
from ISO 8601:2000, thus I think they should be considered as particular cases 
of date-time.
The "T" designator (8601:2004 section 5.3.1.5) already allows unambiguous 
representations

Examples:

For instance, BDAY could be specified as

BDAY Value type:  The default is a date-time value.  It can also be reset to a
text value.

BDAY:19960415
BDAY:19531015T231000Z
BDAY;VALUE=text:circa 1800

And a time valued property could be represented as
X-FOO:T231000Z
instead of
X-FOO:VALUE=time:231000Z

Regards

Javier