DateTimeZone.IsFixed possibly shouldn't be public #62

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

Comments

Projects
None yet
2 participants
@GoogleCodeExporter
DateTimeZone.IsFixed doesn't seem like it's particularly useful to most users - 
and it's not something that I imagine we want people to call in general, so its 
presence in the public API is somewhat confusing.

On the other hand, it is useful information for CachedDateTimeZone (which is 
internal).  We could make IsFixed internal (or possibly protected internal), 
which has the only disadvantage of making it difficult to write 
CachedDateTimeZone externall.

Original issue reported on code.google.com by malcolm.rowe on 18 Apr 2012 at 9:06

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

I think it's potentially useful for users. In particular, if they know it's 
fixed, they know they never need to worry about daylight saving transitions... 
which means they will always be able to unambiguously convert from local to 
zoned date/times.

It's possibly relevant (though certainly not a clincher) that all of 
java.util.TimeZone, org.joda.time.DateTimeZone, and System.TimeZoneInfo all 
support this. We could always make it internal and make it public if requested, 
of course...

Original comment by jonathan.skeet on 18 Apr 2012 at 6:48

I think it's potentially useful for users. In particular, if they know it's 
fixed, they know they never need to worry about daylight saving transitions... 
which means they will always be able to unambiguously convert from local to 
zoned date/times.

It's possibly relevant (though certainly not a clincher) that all of 
java.util.TimeZone, org.joda.time.DateTimeZone, and System.TimeZoneInfo all 
support this. We could always make it internal and make it public if requested, 
of course...

Original comment by jonathan.skeet on 18 Apr 2012 at 6:48

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

If you meant JDK's TimeZone.useDaylightTime(), it looks like that ignores 
historical data, so the guarantee you mention wouldn't hold. (That may be true 
of the other two you mention - the documentation isn't clear.)

Stack Overflow has precisely one reference to Joda's isFixed() method that I 
could find, and that from someone trying to do the wrong thing. I'd be inclined 
to make this protected internal until we see a request for the functionality.

Original comment by malcolm.rowe on 18 Apr 2012 at 8:31

If you meant JDK's TimeZone.useDaylightTime(), it looks like that ignores 
historical data, so the guarantee you mention wouldn't hold. (That may be true 
of the other two you mention - the documentation isn't clear.)

Stack Overflow has precisely one reference to Joda's isFixed() method that I 
could find, and that from someone trying to do the wrong thing. I'd be inclined 
to make this protected internal until we see a request for the functionality.

Original comment by malcolm.rowe on 18 Apr 2012 at 8:31

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

Jon and I looked at _Joda-Time_ usage in a large codebase, and found only 
(non-test) two references to isFixed:

- one was iterating all known timezones and attempting to work out for each a 
reasonable "standard" and "daylight" offset that could be said to represent the 
zone.  Here, isFixed was used as an optimisation, but was not really required.
- the other was attempting to identify a "canonical" timezone that represented 
a given offset; i.e. given simply the offset +0400, return any known timezone 
that had that fixed offset (i.e. that did not observe DST).

The latter is the only use we've seen that would actually require IsFixed.

Original comment by malco...@google.com on 19 Apr 2012 at 2:10

Jon and I looked at _Joda-Time_ usage in a large codebase, and found only 
(non-test) two references to isFixed:

- one was iterating all known timezones and attempting to work out for each a 
reasonable "standard" and "daylight" offset that could be said to represent the 
zone.  Here, isFixed was used as an optimisation, but was not really required.
- the other was attempting to identify a "canonical" timezone that represented 
a given offset; i.e. given simply the offset +0400, return any known timezone 
that had that fixed offset (i.e. that did not observe DST).

The latter is the only use we've seen that would actually require IsFixed.

Original comment by malco...@google.com on 19 Apr 2012 at 2:10

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

Fixed in revision e6937fe3099d.

Original comment by jonathan.skeet on 19 Apr 2012 at 2:13

  • Changed state: Fixed
Fixed in revision e6937fe3099d.

Original comment by jonathan.skeet on 19 Apr 2012 at 2:13

  • Changed state: Fixed
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

I was getting ready to use this, so I'm glad I came across this issue. For one, 
I don't want to use a method that won't be public in a future release, but it 
also doesn't work the way I thought it did. Take Japan Standard Time (JST), for 
example. It doesn't use DST, so I would expect isFixed to return true, but as 
was previously noted, it takes historical data into account. JST observed DST 
from 1948-51, so it returns false.

Original comment by gthazm...@gmail.com on 30 Apr 2012 at 5:11

I was getting ready to use this, so I'm glad I came across this issue. For one, 
I don't want to use a method that won't be public in a future release, but it 
also doesn't work the way I thought it did. Take Japan Standard Time (JST), for 
example. It doesn't use DST, so I would expect isFixed to return true, but as 
was previously noted, it takes historical data into account. JST observed DST 
from 1948-51, so it returns false.

Original comment by gthazm...@gmail.com on 30 Apr 2012 at 5:11

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 15, 2015

Thanks for the comment on this - it's very useful feedback.

The better alternative you're looking for is probably to call 
DateTimeZone.GetZoneInterval for some appropriate instant (e.g. "the start of 
the year 2000") and then check how far back and forward that interval goes - in 
particular, if it ends to infinity going forward (if (zoneInterval.End == 
Instant.MaxValue)), then you know there won't be any transitions after whatever 
instant you choose.

Original comment by jonathan.skeet on 1 May 2012 at 6:55

Thanks for the comment on this - it's very useful feedback.

The better alternative you're looking for is probably to call 
DateTimeZone.GetZoneInterval for some appropriate instant (e.g. "the start of 
the year 2000") and then check how far back and forward that interval goes - in 
particular, if it ends to infinity going forward (if (zoneInterval.End == 
Instant.MaxValue)), then you know there won't be any transitions after whatever 
instant you choose.

Original comment by jonathan.skeet on 1 May 2012 at 6:55

@malcolmr malcolmr added the bug label Mar 15, 2015

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