Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ZonedDateTime formatting and support for time zone abbreviations #216

Closed
GoogleCodeExporter opened this issue Mar 15, 2015 · 4 comments
Closed
Milestone

Comments

@GoogleCodeExporter
Copy link

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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

  • Added labels: Milestone-1.2.0

@malcolmr malcolmr modified the milestone: 1.2.0 Mar 15, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants