You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
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
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.
Original issue reported on code.google.com by germanft...@gmail.com on 25 Apr 2013 at 10:33
The text was updated successfully, but these errors were encountered:
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
Original comment by jonathan.skeet on 25 Apr 2013 at 11:52
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
Original comment by jonathan.skeet on 14 May 2013 at 3:11