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

Bcl provider returns non-bcl zones #332

Closed
GoogleCodeExporter opened this issue Mar 15, 2015 · 5 comments
Closed

Bcl provider returns non-bcl zones #332

GoogleCodeExporter opened this issue Mar 15, 2015 · 5 comments
Labels
bug
Milestone

Comments

@GoogleCodeExporter
Copy link

@GoogleCodeExporter GoogleCodeExporter commented Mar 15, 2015

I would expect something like this to work:

    var bcl = DateTimeZoneProviders.Bcl;
    var zones = bcl.Ids.Select(id => bcl[id])
                       .Cast<BclDateTimeZone>()
                       .Select(x => new {x.Id, x.DisplayName})
                       .ToList();

But it fails since the Bcl provider returns a few zones that are 
FixedDateTimeZone instead of BclDateTimeZone.   Specifically, they are "UTC", 
"UTC+12", "UTC-02", and "UTC-11".

While I understand that these zones *can* be represented as a fixed offset, 
shouldn't they still be delivered as a BclDateTimeZone since I used the Bcl 
provider?

Casting to a BclDateTimeZone is the only way to get at DisplayName, which is 
how I found this.  Other than calling TimeZoneInfo.FindSystemTimeZoneById, I 
can't think of another way to get back a display name such as "(UTC) 
Coordinated Universal Time" without hardcoding it.

Original issue reported on code.google.com by mj1856 on 26 Sep 2014 at 8:58

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Mar 15, 2015

Hmm. The issue is DateTimeZoneCache, which checks whether the ID corresponds to 
a FixedDateTimeZone before it checks the provider. This corresponds with the 
behaviour documented in IDateTimeZoneProvider. (You can ask the provider for 
any fixed-offset zone, whether or not it's in Ids.)

We should probably think about this carefully at the same time as issue 282.

I wish this were a simple implementation issue :(

Original comment by jonathan.skeet on 26 Sep 2014 at 9:15

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Mar 15, 2015

Original comment by malcolm.rowe on 19 Feb 2015 at 1:14

  • Added labels: Milestone-2.0-consider
@malcolmr
Copy link
Contributor

@malcolmr malcolmr commented Mar 15, 2015

If we're doing this at all, it'll have to be for 2.0.0.

@jskeet
Copy link
Member

@jskeet jskeet commented Dec 15, 2016

Note: we probably need to check anything else that uses DateTimeZone.ForOffset and providers, to make sure the precedence is okay.

jskeet added a commit to jskeet/nodatime that referenced this issue Dec 29, 2016
jskeet added a commit to jskeet/nodatime that referenced this issue Dec 29, 2016
malcolmr added a commit to malcolmr/nodatime that referenced this issue Dec 29, 2016
In particular, document that it will be equal to (though not necessarily
the same instance as[*]) whatever DateTimeZone.ForOffset(Offset.Zero)
returns, and clarify that it may not be equal to any zone returned by
IDateTimeZoneProvider["UTC"] (as after nodatime#332 is resolved, it won't be).

Refs nodatime#180.

[*] In practice, DateTimeZone.ForOffset(Offset.Zero) will be the same
    instance as DateTimeZone.Utc (and we have tests to check that), but
    it doesn't need to be.
jskeet added a commit to jskeet/nodatime that referenced this issue Dec 29, 2016
@jskeet jskeet closed this in #619 Dec 29, 2016
jskeet added a commit that referenced this issue Dec 29, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants