Consider how ISO formats with comma subsecond separators should be handled

[GoogleCodeExporter]

ISO-8601 supports and even recommends that seconds should be separated from 
subseconds with a comma:

    15:25:12,123

I've never seen this in the wild, but it may be. Do we want to support this, 
and how?

- Should it be conditional (e.g. only for the invariant culture, or only when 
it's known to be an ISO format)?
- Should it apply to all types? (Think Offset as well as LocalDateTime)
- Should we ever format that way?

Original issue reported on code.google.com by jonathan.skeet on 5 Nov 2012 at 7:35

[GoogleCodeExporter]

(From Richard by mail - please use the issue web site for replies :)

> - Should it be conditional (e.g. only for the invariant culture, or only   
> when it's known to be an ISO format)? 

I think ISO implies the invariant culture.  So should be conditional on 
invariant culture.

> - Should it apply to all types? (Think Offset as well as LocalDateTime) 

Yes.

> - Should we ever format that way? 

Issue 21, says No. And I agree with your comment that this may not be *right*.

Original comment by jonathan.skeet on 6 Nov 2012 at 6:59

[GoogleCodeExporter]

(From Richard by mail - please use the issue web site for replies :)

> - Should it be conditional (e.g. only for the invariant culture, or only   
> when it's known to be an ISO format)? 

I think ISO implies the invariant culture.  So should be conditional on 
invariant culture.

> - Should it apply to all types? (Think Offset as well as LocalDateTime) 

Yes.

> - Should we ever format that way? 

Issue 21, says No. And I agree with your comment that this may not be *right*.

Original comment by jonathan.skeet on 6 Nov 2012 at 6:59

[GoogleCodeExporter]

I think the fact that the ISO patterns only use the invariant culture should be 
seen as incidental - it certainly doesn't mean that whenever you use the 
invariant culture, you're trying to use the ISO format.

If we want to be selective about this, the simplest way is to use a new 
character. ";" seems like an obvious choice, having both a comma and a dot in 
it. I suspect it rarely crops up as literal text which would need escaping, 
too. (I'm still somewhat of a mind to forbid any unquoted literal text other 
than space, but that's a separate matter.)

So the extended ISO format would just become:

    yyyy'-'MM'-'dd'T'HH':'mm':'ss;FFFFFFF

Thoughts?

Original comment by jonathan.skeet on 6 Nov 2012 at 7:02

[GoogleCodeExporter]

I think the fact that the ISO patterns only use the invariant culture should be 
seen as incidental - it certainly doesn't mean that whenever you use the 
invariant culture, you're trying to use the ISO format.

If we want to be selective about this, the simplest way is to use a new 
character. ";" seems like an obvious choice, having both a comma and a dot in 
it. I suspect it rarely crops up as literal text which would need escaping, 
too. (I'm still somewhat of a mind to forbid any unquoted literal text other 
than space, but that's a separate matter.)

So the extended ISO format would just become:

    yyyy'-'MM'-'dd'T'HH':'mm':'ss;FFFFFFF

Thoughts?

Original comment by jonathan.skeet on 6 Nov 2012 at 7:02

[GoogleCodeExporter]

So simple using ";" You got my vote.

Original comment by makaretu on 6 Nov 2012 at 7:34

[GoogleCodeExporter]

So simple using ";" You got my vote.

Original comment by makaretu on 6 Nov 2012 at 7:34

[GoogleCodeExporter]

Implemented (not committed); still need to update docs. Will be in 1.0.

Original comment by jonathan.skeet on 6 Nov 2012 at 9:32

• Changed state: Started
• Added labels: Milestone-1.0
• Removed labels: Milestone-1.0-consider

[GoogleCodeExporter]

Implemented (not committed); still need to update docs. Will be in 1.0.

Original comment by jonathan.skeet on 6 Nov 2012 at 9:32

• Changed state: Started
• Added labels: Milestone-1.0
• Removed labels: Milestone-1.0-consider

[GoogleCodeExporter]

This issue was closed by revision 83828680f3fe.

Original comment by jonathan.skeet on 6 Nov 2012 at 2:08

• Changed state: Fixed

[GoogleCodeExporter]

This issue was closed by revision 83828680f3fe.

Original comment by jonathan.skeet on 6 Nov 2012 at 2:08

• Changed state: Fixed

[GoogleCodeExporter]

This issue was closed by revision 9d7463af820e.

Original comment by jonathan.skeet on 6 Nov 2012 at 7:02

[GoogleCodeExporter]

This issue was closed by revision 9d7463af820e.

Original comment by jonathan.skeet on 6 Nov 2012 at 7:02

[GoogleCodeExporter]

Original comment by malcolm.rowe on 10 Nov 2012 at 10:20

• Added labels: Milestone-1.0.0
• Removed labels: Milestone-1.0

[GoogleCodeExporter]

Original comment by malcolm.rowe on 10 Nov 2012 at 10:20

• Added labels: Milestone-1.0.0
• Removed labels: Milestone-1.0