Bcl provider returns non-bcl zones #332

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

Comments

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

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter 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

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.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

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

  • Added labels: Milestone-2.0-consider

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

  • Added labels: Milestone-2.0-consider
@malcolmr

This comment has been minimized.

Show comment
Hide comment
@malcolmr

malcolmr Mar 15, 2015

Contributor

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

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.

Show comment
Hide comment
@jskeet

jskeet Dec 15, 2016

Member

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

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 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 #332 is resolved, it won't be).

Refs #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 #332 is resolved, it won't be).

Refs #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