It's worth noting that for InstantPattern, the general pattern as defined by 
the "g" standard format specifier is indeed ISO... whereas LocalDatePattern 
doesn't *have* a "g" standard format specifier. LocalDateTimePattern does, but 
it's not ISO... (and it's not invariant).

Basically, we have three concepts - roundtrip, general (i.e. general standard 
format pattern, "g"), and ISO. In some cases they coincide, in others they 
don't. How should we name them in code?

One thing we *may* want to do is create a factory method / property 
corresponding to every standard format pattern in every type. So we could have 
LocalDatePattern.GetShortPattern(CultureInfo) for example.

Arguably we could also have a new type "Patterns" such that you could have:

    Patterns.GetShortDatePattern
    Patterns.GetLongDatePattern
    Patterns.GetShortDateTimePattern
    // etc

Admittedly the name "Patterns" is already a namespace name, which doesn't help.

We may well want to punt this until v1.1 though. Really not sure what to do 
with the current properties...

Good catch, Richard. (If we don't get round to fixing the docs before 1.0, 
that's okay - but obviously we should do so soon.) It still irks me that 
ISO-8601 recommends using "," as the deicmal separator, when I've *never* seen 
that in the real world. I don't think we handle that when parsing, either...

It's a common decimal separator *for numbers* in various countries, but I've 
never seen it used *in times* as ISO suggests.

Originally we made "." in a time-related pattern map to the culture-specific 
decimal separator, but I changed back to always using "." as that's what the 
BCL does. Note that our ISO patterns are invariant, so it sort-of makes sense 
for them to use a dot... but it does mean we couldn't parse examples from 
ISO-8601 itself. Hmm. (Probably worth this all going into a separate issue...)

This will take significant thought, and should be done properly. The existing 
state of play isn't abysmal, just inconsistent. Will leave as-is for 1.0.

In 1.1 we should create a new and whizzy set of consistent conventions, 
deprecating any names we don't like any more.

In 2.0 we can then remove the obsolete names.

I think we're done until 2.0 now - the names may not be ideal, but they're not 
awful.

More static methods for *creating* patterns would be feasible, but needn't be 
targeted at a particular release.