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

Comments

Projects
None yet
3 participants
@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

This comment has been minimized.

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

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

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

  • Added labels: Milestone-2.0-consider
@malcolmr

This comment has been minimized.

Contributor

malcolmr commented Mar 15, 2015

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

@jskeet

This comment has been minimized.

Member

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

This comment has been minimized.

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

Document guarantees around DateTimeZone.Utc equality.
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

DibbyDum added a commit to DibbyDum/nodatime that referenced this issue Jan 31, 2017

Document guarantees around DateTimeZone.Utc equality.
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.

DibbyDum added a commit to DibbyDum/nodatime that referenced this issue Jan 31, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment