Re: [threeten-develop] ZonedDateTime

[Douglas S. <dou...@or...>]

I strongly disagree. Unless a ZonedDateTime created with the 
most_recent_version tracks changes to the ZoneRules, I'd argue that 
it is nearly useless.

I have a meeting scheduled for 10am Monday morning America/Los 
Angeles. That is +07:00 so 1700UTC. The rules change to move the time 
change to Sunday so 10am Monday is +08:00 or 1800UTC. If 
ZonedDateTime is not responsive to rule changes then my calendar 
program will alert me for the meeting an hour early. This is not a 
special case. This is the most common use case for ZonedDateTime.

As for the immutability argument, changing the environment in which 
an immutable value is processed may change the results of some 
methods, but does not make the value mutable. For example no one 
doubts that java.lang.String is immutable yet consider the following:


   String a = "a";
   bytes[] b0 = a.getBytes();
   Locale.setDefault(...);
   bytes[] b1 = a.getBytes();
   System.out.println(java.util.Arrays.equals(b0, b1));

No one would be surprised if the above printed "false" yet Strings 
are immutable. Changing the ZoneRules is exactly the same. We 
discussed this last year and it seemed to me that you agreed.

Douglas


At 03:51 AM 10/13/2011, Stephen Colebourne wrote:
>The design is intended to ensure that once you have a ZonedDateTime
>object, you will never see it change. This is important for
>immutability reasons.
>
>If changes were permitted, the following code (valid if weird) could 
>fail:
>
>if (zdt.getHour() < 3) {
>   zdt = zdt.plusHours(3 - zdt.getHour());
>}
>
>The system works by locking the ZDT to the latest set of rules that
>are valid for the stored OffsetDateTime. Thus, the object appears
>stable even if new zone info is added that makes the ZDT invalid if
>recreated.
>
>What we don't have is a way to force the ZDT to resolve to the 
>latest
>set of rules, currently
>  ZonedDateTime correctNow = zdt.withZoneSameInstant(zdt.getZone());
>could be
>  ZonedDateTime correctNow = zdt.withLatestZoneRules();
>
>However, I do think its a specialist method, and I'm not sure that 
>I'd
>want to add the clutter.
>
>Stephen
>
>
>On 12 October 2011 22:41, Douglas Surber <dou...@or...> 
>wrote:
> > Stephen,
> >
> > Last year we discussed what it meant when TimeZoneRules are 
> updated
> > with a new version. I thought we had agreed that a ZonedDateTime
> > would possibly refer to a different Instant with the same
> > LocalDateTime depending on the differences between the previous
> > version of the rules and the new version. If that is the case, 
> then I
> > don't understand how ZonedDateTime.getOffset works.
> >
> >
> >     public ZoneOffset getOffset() {
> >         return dateTime.getOffset();
> >     }
> >
> > A ZoneOffset is just a fixed number of seconds an dateTime is an
> > OffsetDateTime which knows nothing about TimeZoneRules.
> >
> > I would have thought it should look something like
> >
> >
> >     public ZoneOffset getOffset() {
> >       return getApplicableRules()
> >                 .getOffsetInfo(dateTime.toLocalDateTime())
> >                 .getEstimatedOffset();
> >     }
> >
> >
> > I'm sure there are better ways to implement this, but the point
> > remains; ZonedDateTime should be sensitive to changes is the
> > ZoneRules version and the current implementation does not appear 
> to
> > be. Is this correct or am I missing something?
> >
> > The same appears to be true for getYear, getMonthOfYear, ...,
> > getNanoOfSecond including getHourOfDay. They are not sensitive to
> > changes in the rules. Generally they shouldn't change even with
> > changes in the ZoneRules. The one exception would be if a 
> previously
> > valid LocalDateTime is made invalid by the new version of the 
> rules.
> > In that case the returned values could change. For example if the
> > clocks are set ahead one hour at 23:00 on Dec 31, the year 
> returned
> > for Dec 31, 23:30 would change. Or so it would seem to me.
> >
> > Douglas
> >
> >
> > 
> ------------------------------------------------------------------------------
> > All the data continuously generated in your IT infrastructure 
> contains a
> > definitive record of customers, application performance, security
> > threats, fraudulent activity and more. Splunk takes this data and 
> makes
> > sense of it. Business sense. IT sense. Common sense.
> > http://p.sf.net/sfu/splunk-d2d-oct
> > _______________________________________________
> > threeten-develop mailing list
> > thr...@li...
> > https://lists.sourceforge.net/lists/listinfo/threeten-develop
> >
>
>------------------------------------------------------------------------------
>All the data continuously generated in your IT infrastructure 
>contains a
>definitive record of customers, application performance, security
>threats, fraudulent activity and more. Splunk takes this data and 
>makes
>sense of it. Business sense. IT sense. Common sense.
>http://p.sf.net/sfu/splunk-d2d-oct
>_______________________________________________
>threeten-develop mailing list
>thr...@li...
>https://lists.sourceforge.net/lists/listinfo/threeten-develop