ZonedDateTime formatting and support for time zone abbreviations

[GoogleCodeExporter]

Hi!

I would like to display ZonedDateTime to the user with some kind of formatting 
and info of the timezone.

Currently calling ToString() on a ZonedDateTime yields something like this 
(es-ES Culture) in Madrid.

Local: 25/04/2013 11:50 Offset: +02 Zone: Europe/Paris

It would be nice to:

1) Give ZonedDateTime better ToString support as other Noda types have
2) Support standard/daylight/summer abbreviations in the 
formatting. (I think this info is in the tz database sources, but NodaTime 
currently doesnt seem to use it)
3) Make reasonably formatting defaults for a ZonedDateTime including the 
systems culture (for example show CET in culture "es-ES" but MEZ if culture 
"de-DE")

Formatting examples:
25/04/2013 11:50 CEST
25/04/2013 11:50 MESZ
25/04/2013 11:50 CEST (UTC+2)
25/04/2013 11:50 UTC+02

I suppose this is a very low priority item, as the user generally does not care 
about their timezone abbreviation, but it may be useful to give feedback to the 
user that this is ZonedDateTime according to a time zone, specially when you 
want to display a ZonedDateTime that originates in a different timezone that 
the one the user is on.

I think that the OffsetDateTime formatting can also be improved.

Germán

Original issue reported on code.google.com by germanft...@gmail.com on 25 Apr 2013 at 10:33

[GoogleCodeExporter]

Full ZonedDateTime pattern support is on the roadmap for 1.2 (and present in 
source control in ZonedDateTimePattern and indeed OffsetDateTimePattern). 
However, I have no current goal of supporting abbreviations. They're 
misleading, poorly understood, and often ambiguous. (Think about what the 
*parsing* side would need to work out). Having different abbreviations for the 
same time zone in different cultures makes the whole thing even messier.

It's possible that we'll address this at some point, but I'd rather not do it 
at all than do it poorly - and at the moment it's not clear how we'd do it well.

Note that when we start using CLDR data in 1.3, we should start being able to 
present a more "location-oriented" view of time zones, and one which uses 
different cultures appropriately. That's still very much TBD at the moment 
though.

Original comment by jonathan.skeet on 25 Apr 2013 at 11:52

• Added labels: Type-Enhancement

[GoogleCodeExporter]

Format-only support is included in revision 4bb395aca17c.

I'm still not 100% sure we want this at all, and if we do have it we *may* want 
to make it parseable (although that would probably be extremely slow, and lead 
to ambiguities).

Original comment by jonathan.skeet on 14 May 2013 at 3:11

[GoogleCodeExporter]

Marking this as fixed for now, with abbreviations being format-only.

Original comment by jonathan.skeet on 26 Jul 2013 at 4:44

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by malcolm.rowe on 26 Jul 2013 at 10:02

• Added labels: Milestone-1.2.0