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
