Internally, J-T calculates using "local millis" which is a count based
on epoch millis with the offset removed. This is in effect identical
to UTC.
After you setMillis(0), you can do a toString(), and you will see the
time is 01:00. When this is rounded to the nearest day you get a time
of 00:00 (which happens to be -3600000 in UTC millis).
But rounding a time of 01:00 to the nearest minute will not change
anything, and gives 01:00.
The problem is that you are focussing on getting the millis, rather
than on the toString() value, which is correct.
Stephen
On 29 December 2011 17:02, Shay Banon <kim...@gmail.com> wrote:
> Grr, I started to try and build something that would do the rounding I need,
> but I feel like I might be missing something in Joda that will help me and
> not cause me to write all this code.
>
> Recap of what I am trying to do: Have a list of UTC millis, and want to
> bucket them based on rounding and time zone. The buckets can be either UTC
> millis rounded, or time zone offset, I don't mind, but obviously, rounding
> should take timezone into account.
>
> Going back to my first sample, when I use dayOfMonth:
>
> MutableDateTime time = new MutableDateTime(DateTimeZone.UTC);
> time.setZone(DateTimeZone.forOffsetHours(1));
> time.setRounding(time.getChronology().dayOfMonth(),
> MutableDateTime.ROUND_FLOOR);
> time.setMillis(0);
> time.getMilli();
>
> I get back -3600000, which is basically 1 hour before 0. What happens is
> that the millis are offseted by the time zone, then floored by day, and
> then the timezone is applied again. The result is not UTC.
>
> On the other hand, when I use minutOfHour instead of day, I get back 0,
> which is UTC.
>
> I need something that is consistent regardless of the rounding applied (day,
> minute, hour), is there a way to do it with Joda "easily", or do I need to
> write something myself, that does not convert back from local to UTC if
> using certain rounding?
>
>
>
>
> On Thu, Dec 29, 2011 at 11:09 AM, Stephen Colebourne <scolebou...@joda.org>
> wrote:
>>
>> While I haven't tested it, I'd expect something like that to work (and
>> be reasonably performant). Best advice is to write some decent unit
>> tests and check it that way!
>> Stephen
>>
>> On 28 December 2011 21:42, Shay Banon <kim...@gmail.com> wrote:
>> > Heya,
>> >
>> > Yea, I see the problem with converting back to UTC after the rounding.
>> > But, if I want to keep it in millis since the epoch offset by time zone,
>> > will this code work ok?:
>> >
>> > DateTimeZone timeZone = <<some timezone>>
>> > long utcMillis = <<some number>>
>> >
>> > MutableDateTime time = new MutableDateTime(DateTimeZone.UTC);
>> > time.setRounding(time.getChronology().minuteOfDay(),
>> > MutableDateTime.ROUND_FLOOR);
>> > time.setMillis(utcMillis + timeZone.getOffset(utcMillis));
>> > long actualValue = time.getMillis();
>> >
>> > I am still using MutableDateTime with UTC, but passing it the offset
>> > millis
>> > so it will do the rounding for me. I can work around not even using
>> > MutableDateTime by using DateTimeField from the chronology directly and
>> > calling the correct round method.
>> >
>> > Does that make sense?
>> >
>> > On Wed, Dec 28, 2011 at 1:25 PM, Stephen Colebourne
>> > <scolebou...@joda.org>
>> > wrote:
>> >>
>> >> Well, when you create a MutableDateTime with an offset, then all
>> >> operations on that class have the offset applied.
>> >>
>> >> Rounding to midnight (which is what the dayOfMonth rounding does) will
>> >> therefore produce a toString() at midnight. Rounding to nearest minute
>> >> will round within the offset/time-zone context, but that makes no
>> >> difference to the result.
>> >>
>> >> If you need greater control than the standard classes are providing,
>> >> then you'll need to manage the offset yourself. See the DateTimeZone
>> >> class for methods to get the offset.
>> >>
>> >> Stephen
>> >>
>> >>
>> >> On 22 December 2011 23:17, Shay Banon <kim...@gmail.com> wrote:
>> >> > Let me try and explain what I am trying to do, maybe I have gone the
>> >> > wrong
>> >> > way to try and achieve it. Basically, I have a list of utc millis
>> >> > since
>> >> > epoch, and I would like to build a histogram bucking them, but I want
>> >> > it
>> >> > to
>> >> > be built by also taking a custom time zone into account. The return
>> >> > value of
>> >> > each bucket should be skewed by the time zone to be millis since the
>> >> > epoch
>> >> > based on that time zone.
>> >> >
>> >> > I used MutableDateTime, initialized it with the relevant time zone,
>> >> > and
>> >> > then
>> >> > the rounding, and basically setMillis and getMillis for it. It works
>> >> > well
>> >> > with day rounding, but with minute rounding, I still get back the utc
>> >> > millis, and not ones epoch skewed by the time zone.
>> >> >
>> >> > The main reason for returning bucket start time in time zone based
>> >> > millis
>> >> > since epoch is to simplify graphing the results.
>> >> >
>> >> > Does that make sense? Is there a better way to do it?
>> >> >
>> >> >
>> >> > On Fri, Dec 23, 2011 at 12:13 AM, Stephen Colebourne
>> >> > <scolebou...@joda.org>
>> >> > wrote:
>> >> >>
>> >> >> When you choose dayOfMonth, you are asking to round to the nearest
>> >> >> day, where as with minuteOfHour you are asking to round to the
>> >> >> nearest
>> >> >> minute. The rounding occurs relative to the offset.
>> >> >>
>> >> >> The millis value for the date is simply a reflection of the offset.
>> >> >> The rounding applies to the local date time, which is why both the
>> >> >> +01:00 and UTC offsets print a time of midnight.
>> >> >>
>> >> >> Stephen
>> >> >>
>> >> >> On 22 December 2011 21:13, Shay Banon <kim...@gmail.com> wrote:
>> >> >> > Heya,
>> >> >> >
>> >> >> > I got this strange behavior with rounding and timezone.
>> >> >> > Depending
>> >> >> > on
>> >> >> > the
>> >> >> > type of rounding (dayOfMonth vs. minuteOfHour) I am getting
>> >> >> > different
>> >> >> > results for the same rounded value. The following code runs with
>> >> >> > dayOfMonth:
>> >> >> >
>> >> >> > MutableDateTime time = new
>> >> >> > MutableDateTime(DateTimeZone.UTC);
>> >> >> > time.setZone(DateTimeZone.forOffsetHours(1));
>> >> >> > time.setRounding(time.getChronology().dayOfMonth(),
>> >> >> > MutableDateTime.ROUND_FLOOR);
>> >> >> >
>> >> >> > MutableDateTime utcTime = new
>> >> >> > MutableDateTime(DateTimeZone.UTC);
>> >> >> > utcTime.setRounding(utcTime.getChronology().dayOfMonth(),
>> >> >> > MutableDateTime.ROUND_FLOOR);
>> >> >> >
>> >> >> > time.setMillis(0);
>> >> >> > utcTime.setMillis(0);
>> >> >> > System.out.println("time: " + time + ", utc " + utcTime);
>> >> >> > System.out.println("time_millis: " + time.getMillis() + ",
>> >> >> > utc_millis " + utcTime.getMillis());
>> >> >> >
>> >> >> > And the output shows that the time millis differ between the utc
>> >> >> > one,
>> >> >> > and
>> >> >> > the time zone one. On the other hand, just changing to round based
>> >> >> > on
>> >> >> > minuteOfHour, results in the millis between the two to be the
>> >> >> > same:
>> >> >> >
>> >> >> > MutableDateTime time = new
>> >> >> > MutableDateTime(DateTimeZone.UTC);
>> >> >> > time.setZone(DateTimeZone.forOffsetHours(1));
>> >> >> > time.setRounding(time.getChronology().minuteOfHour(),
>> >> >> > MutableDateTime.ROUND_FLOOR);
>> >> >> >
>> >> >> > MutableDateTime utcTime = new
>> >> >> > MutableDateTime(DateTimeZone.UTC);
>> >> >> >
>> >> >> > utcTime.setRounding(utcTime.getChronology().minuteOfHour(),
>> >> >> > MutableDateTime.ROUND_FLOOR);
>> >> >> >
>> >> >> > time.setMillis(0);
>> >> >> > utcTime.setMillis(0);
>> >> >> > System.out.println("time: " + time + ", utc " + utcTime);
>> >> >> > System.out.println("time_millis: " + time.getMillis() + ",
>> >> >> > utc_millis " + utcTime.getMillis());
>> >> >> >
>> >> >> >
>> >> >> > I must be missing something obvious, but I don't understand why
>> >> >> > the
>> >> >> > results
>> >> >> > would be different between the two runs? The results of the two
>> >> >> > runs
>> >> >> > should
>> >> >> > be the same (and I think they all should have 0 as millis, no?).
>> >> >> >
>> >> >> > -shay.banon
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > ------------------------------------------------------------------------------
>> >> >> > Write once. Port to many.
>> >> >> > Get the SDK and tools to simplify cross-platform app development.
>> >> >> > Create
>> >> >> > new or port existing apps to sell to consumers worldwide. Explore
>> >> >> > the
>> >> >> > Intel AppUpSM program developer opportunity.
>> >> >> > appdeveloper.intel.com/join
>> >> >> > http://p.sf.net/sfu/intel-appdev
>> >> >> > _______________________________________________
>> >> >> > Joda-interest mailing list
>> >> >> > Joda-interest@lists.sourceforge.net
>> >> >> > https://lists.sourceforge.net/lists/listinfo/joda-interest
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> ------------------------------------------------------------------------------
>> >> >> Write once. Port to many.
>> >> >> Get the SDK and tools to simplify cross-platform app development.
>> >> >> Create
>> >> >> new or port existing apps to sell to consumers worldwide. Explore
>> >> >> the
>> >> >> Intel AppUpSM program developer opportunity.
>> >> >> appdeveloper.intel.com/join
>> >> >> http://p.sf.net/sfu/intel-appdev
>> >> >> _______________________________________________
>> >> >> Joda-interest mailing list
>> >> >> Joda-interest@lists.sourceforge.net
>> >> >> https://lists.sourceforge.net/lists/listinfo/joda-interest
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > Write once. Port to many.
>> >> > Get the SDK and tools to simplify cross-platform app development.
>> >> > Create
>> >> > new or port existing apps to sell to consumers worldwide. Explore the
>> >> > Intel AppUpSM program developer opportunity.
>> >> > appdeveloper.intel.com/join
>> >> > http://p.sf.net/sfu/intel-appdev
>> >> > _______________________________________________
>> >> > Joda-interest mailing list
>> >> > Joda-interest@lists.sourceforge.net
>> >> > https://lists.sourceforge.net/lists/listinfo/joda-interest
>> >> >
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Write once. Port to many.
>> >> Get the SDK and tools to simplify cross-platform app development.
>> >> Create
>> >> new or port existing apps to sell to consumers worldwide. Explore the
>> >> Intel AppUpSM program developer opportunity.
>> >> appdeveloper.intel.com/join
>> >> http://p.sf.net/sfu/intel-appdev
>> >> _______________________________________________
>> >> Joda-interest mailing list
>> >> Joda-interest@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/joda-interest
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
>> > complex
>> > infrastructure or vast IT resources to deliver seamless, secure access
>> > to
>> > virtual desktops. With this all-in-one solution, easily deploy virtual
>> > desktops for less than the cost of PCs and save 60% on VDI
>> > infrastructure
>> > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
>> > _______________________________________________
>> > Joda-interest mailing list
>> > Joda-interest@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/joda-interest
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
>> infrastructure or vast IT resources to deliver seamless, secure access to
>> virtual desktops. With this all-in-one solution, easily deploy virtual
>> desktops for less than the cost of PCs and save 60% on VDI infrastructure
>> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
>> _______________________________________________
>> Joda-interest mailing list
>> Joda-interest@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Joda-interest mailing list
> Joda-interest@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Joda-interest mailing list
Joda-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/joda-interest
