Subject: [Jcardcal] Deciding on the Date format

From: Philipp Kewisch <[email-masked]>
Date: Wed, 24 Apr 2013 23:49:18 +0200

Reading both ISO.8601.2000 and ISO.8601.2004 I have put together an 
overview of all possible combinations allowed by RFC6350, along with 
their extended representation from ISO 8601.

I don't see any ambiguities here following the rule "if there is no 
extended representation, use the basic one". Of course there may be an 
additional hurdle in implementing a converter and handling date formats, 
but I think this is manageable.

An additional note, the Javascript Date constructor allows passing most 
of these representations, except for the truncated representation. The 
resulting Date for reduced accuracy uses whatever is passed and fills in 
the lowest possible value for what is left out. I must admit I've only 
checked a few, not all possible combinations.

Going forward, I think we should stick with the extended representation 
where possible. I will slightly modify the text to make more clear that 
the complete representation is not mandatory, but reduced and truncated 
format can be used. Also, given there was a bit more discussion on the 
date formats, I think it makes sense to include tables like these as an 
informative reference, either in the appendix or within the section for 
the respective type.

I will put together a draft version with previously discussed changes by 
the end of the week and incorporate the date changes in the next version.

If anyone has more doubts or comments regarding the date format, please 
reply.

DATE:
   +-----------+----------+------------+
   |           | Basic    | Extended   |
   +-----------+----------+------------+
   | Complete  | 19850412 | 1985-04-12 |
   +-----------+----------+------------+
   | Reduced   |  1985-04 |    n/a     |
   |           |     1985 |    n/a     |
   +-----------+----------+------------+
   | Truncated |   --0412 |  --04-12   |
   |           |   --04   |    n/a     |
   |           |   ---12  |    n/a     |
   +-----------+----------+------------+

TIME:
   +-----------+----------+------------+
   |           | Basic    | Extended   |
   +-----------+----------+------------+
   | Complete  |   232050 |   23:20:50 |
   +-----------+----------+------------+
   | Reduced   |     2320 |      23:20 |
   |           |       23 |    n/a     |
   +-----------+----------+------------+
   | Truncated |    -2050 |     -20:50 |
   |           |      -20 |    n/a     |
   |           |     --50 |    n/a     |
   +-----------+----------+------------+

DATE-TIME:
   +-----------+----------------------+---------------------------+
   |           | Basic                | Extended                  |
   +-----------+----------------------+---------------------------+
   | Complete  | 19850412T101530      | 1985-04-12T10:15:30       |
   |           | 19850412T101530Z     | 1985-04-12T10:15:30Z      |
   |           | 19850412T101530+0400 | 1985-04-12T10:15:30+04:00 |
   |           | 19850412T101530+04   | 1985-04-12T10:15:30+04    |
   +-----------+----------------------+---------------------------+
   | Reduced   | 19850412T2320        | 1985-04-12T23:20          |
   |    and    | 19850412T23          | 1985-04-12T23             |
   | Truncated | --0412T2320          | --04-12T23:20             |
   |           | --04T2320            | --04T23:20                |
   |           | ---12T23:20          | ---12T23:20               |
   |           | --0412T23            | --04-12T23                |
   |           | --04T23              |    n/a                    |
   |           | ---12T23             |    n/a                    |
   |           | Note: The date component shall not be            |
   |           |       represented with reduced accuracy and the  |
   |           |       time component shall not be truncated.     |
   |           | Note2: All combinations may have any zone        |
   |           |        designator appended, as in the complete   |
   |           |        representation.                           |
   +-----------+----------------------+---------------------------+

DATE-AND-OR-TIME

combination of all of the above.  To allow unambiguous interpretation, a 
stand-alone TIME value is always preceded by a "T".

I couldn't see any ambiguities here

TIMESTAMP
   +-----------+----------------------+---------------------------+
   |           | Basic                | Extended                  |
   +-----------+----------------------+---------------------------+
   | Complete  | 19850412T101530      | 1985-04-12T10:15:30       |
   |           | 19850412T101530Z     | 1985-04-12T10:15:30Z      |
   |           | 19850412T101530+0400 | 1985-04-12T10:15:30+04:00 |
   |           | 19850412T101530+04   | 1985-04-12T10:15:30+04    |
   +-----------+----------------------+---------------------------+

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 26 Apr 2013 12:37:22 -0600

["hats", {}, "text", "individual"]

> their extended representation from ISO 8601.

Thanks, this is helpful.

> but I think this is manageable.

I agree that the conversions between basic and extended are straightforward.

> the lowest possible value for what is left out. 

That strikes me as a bit odd, but it's nothing we're going to change
here since it's part of the language.

> I must admit I've only
> where possible. 

Makes sense to me.

> I will slightly modify the text to make more clear that
> format can be used. 

Will your proposed text indicate a preference of complete over reduced
and reduced over truncated, or do you think that they are all equally
acceptable?

> Also, given there was a bit more discussion on the

Sounds good.

Peter

> _______________________________________________
> jcardcal mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jcardcal

---

From: Philipp Kewisch <[email-masked]>
Date: Fri, 26 Apr 2013 20:41:53 +0200

> and reduced over truncated, or do you think that they are all equally
I think they are all equally acceptable, since each has their own 
purpose. For example, a user may decide not to disclose his or her age 
by omitting the year in the birth date. Essentially, all we are changing 
is the separator, the semantics suggested in rfc6350 should still apply. 
These semantics don't make any restrictions to what order of preference 
applies.

Philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 26 Apr 2013 12:51:13 -0600

Still as individual...

> These semantics don't make any restrictions to what order of preference

Thanks for the clarification.

One more question. You said:

   An additional note, the Javascript Date constructor allows passing
   most of these representations, except for the truncated
   representation. The resulting Date for reduced accuracy uses
   whatever is passed and fills in the lowest possible value for what
   is left out.

If I understood that correctly, a reduced accuracy date of '1985' would
actually get "filled in" as '1985-01-01'. Yes?

Peter

---

From: Philipp Kewisch <[email-masked]>
Date: Fri, 26 Apr 2013 21:06:08 +0200

> actually get "filled in" as '1985-01-01'. Yes?
Indeed, your example is correct. I've tested all formats in Firefox now, 
here are my results:

{
  "1985-04-12": "Fri Apr 12 1985 02:00:00 GMT+0200 (CEST)",
  "1985-04": "Mon Apr 01 1985 02:00:00 GMT+0200 (CEST)",
  "1985": "Tue Jan 01 1985 01:00:00 GMT+0100 (CET)",
  "--04-12": "Invalid Date",
  "--04": "Invalid Date",
  "---12": "Invalid Date",
  "23:20:50": "Invalid Date",
  "23:20": "Invalid Date",
  "23": "Invalid Date",
  "-20:50": "Invalid Date",
  "-20": "Invalid Date",
  "--50": "Invalid Date",
  "T23:20:50": "Thu Jan 01 1970 23:20:50 GMT+0100 (CET)",
  "T23:20": "Thu Jan 01 1970 23:20:00 GMT+0100 (CET)",
  "T23": "Invalid Date",
  "T-20:50": "Invalid Date",
  "T-20": "Invalid Date",
  "T--50": "Invalid Date",
  "1985-04-12T10:15:30": "Fri Apr 12 1985 10:15:30 GMT+0200 (CEST)",
  "1985-04-12T23:20": "Fri Apr 12 1985 23:20:00 GMT+0200 (CEST)",
  "1985-04-12T23": "Invalid Date",
  "--04-12T23:20": "Invalid Date",
  "--04T23:20": "Invalid Date",
  "---12T23:20": "Invalid Date",
  "--04-12T23": "Invalid Date",
  "--04T23": "Invalid Date",
  "---12T23": "Invalid Date"
}

"T-20:50", "T-20", "T--50",

"T-20:50", "T-20", "T--50",

---

From: Michael Angstadt <[email-masked]>
Date: Fri, 26 Apr 2013 15:08:32 -0400

> actually get "filled in" as '1985-01-01'. Yes?

No.  Unless I'm mistaken, "1985" means that no month or date were
specified at all.  Therefore, a date of "1985" should *not* be
converted to "1985-01-01".  It just means "the year 1985".  How the
jCard/jCal consumer chooses to interpret this is up to them, I
suppose.

Mike

---

From: Philipp Kewisch <[email-masked]>
Date: Fri, 26 Apr 2013 21:14:55 +0200

> jCard/jCal consumer chooses to interpret this is up to them, I
Of course, on the level of jCard, "1985" means just the year, no month 
or day. I was just noting that it gets expanded to 1985-01-01T00:00:00 + 
your timezone offset when you feed it into new Date("1985"); This is the 
part where its up to the consumer as you mentioned.

Philipp

---

From: Michael Angstadt <[email-masked]>
Date: Fri, 26 Apr 2013 15:16:29 -0400

On Fri, Apr 26, 2013 at 3:14 PM, Philipp Kewisch <[email-masked]> wrote:
> I was just noting that it gets expanded to 1985-01-01T00:00:00 + your
> timezone offset when you feed it into new Date("1985");

Ah ok, got it.

---

From: Michael Angstadt <[email-masked]>
Date: Sun, 28 Apr 2013 10:35:26 -0400

> I couldn't see any ambiguities here

I don't see any ambiguities either.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 29 Apr 2013 21:49:34 -0600

On 4/26/13 1:06 PM, Philipp Kewisch wrote:
>> An additional note, the Javascript Date constructor allows
>> passing most of these representations, except for the truncated 
>> whatever is passed and fills in the lowest possible value for
>> what is left out.
>> 
>> If I understood that correctly, a reduced accuracy date of '1985'
>> would actually get "filled in" as '1985-01-01'. Yes?
> Indeed, your example is correct. I've tested all formats in Firefox
> now, here are my results:
> 
> { "1985-04-12": "Fri Apr 12 1985 02:00:00 GMT+0200 (CEST)", 
> "1985-04": "Mon Apr 01 1985 02:00:00 GMT+0200 (CEST)", "1985": "Tue
> Jan 01 1985 01:00:00 GMT+0100 (CET)", "--04-12": "Invalid Date", 
> "--04": "Invalid Date", "---12": "Invalid Date", "23:20:50":
> "Invalid Date", "23:20": "Invalid Date", "23": "Invalid Date", 
> "-20:50": "Invalid Date", "-20": "Invalid Date", "--50": "Invalid
> Date", "T23:20:50": "Thu Jan 01 1970 23:20:50 GMT+0100 (CET)", 
> "T23:20": "Thu Jan 01 1970 23:20:00 GMT+0100 (CET)", "T23":
> "Invalid Date", "T-20:50": "Invalid Date", "T-20": "Invalid Date", 
> "T--50": "Invalid Date", "1985-04-12T10:15:30": "Fri Apr 12 1985
> 10:15:30 GMT+0200 (CEST)", "1985-04-12T23:20": "Fri Apr 12 1985
> 23:20:00 GMT+0200 (CEST)", "1985-04-12T23": "Invalid Date", 
> "--04-12T23:20": "Invalid Date", "--04T23:20": "Invalid Date", 
> "---12T23:20": "Invalid Date", "--04-12T23": "Invalid Date", 
> "--04T23": "Invalid Date", "---12T23": "Invalid Date" }
> 

(as chair)

Thanks, Philipp, that is helpful.

Feel free to either post your proposed text to the list for further
discussion, or to submit a revised I-D.

Are you aware of any other significant open issues? If not, Bert and I
think we're close to being able to issue a last call...

Peter

---

From: Philipp Kewisch <[email-masked]>
Date: Tue, 30 Apr 2013 08:59:06 +0200

> think we're close to being able to issue a last call...
Hey Peter,

I will post the new draft version within the next few hours. I am not 
aware of any remaining issues, I think we have discussed all of them.

Philipp