From: Shay Banon <kimchy@gm...>  20111229 18:24:14

Right, I saw that toString handles it nicely, but I still need the millis. Its basically an API that returns bucketed results with counts, and the bucket value is millis for simplicity (so the user won't need to parse a formatted string). Is there a way to get the "correct" millis? On Thu, Dec 29, 2011 at 7:48 PM, Stephen Colebourne <scolebourne@...>wrote: > Internally, JT 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 <kimchy@...> 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 < > scolebourne@...> > > 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 <kimchy@...> 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 > >> > <scolebourne@...> > >> > 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/timezone 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 <kimchy@...> 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 > >> >> > <scolebourne@...> > >> >> > 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 <kimchy@...> 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 crossplatform 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/intelappdev > >> >> >> > _______________________________________________ > >> >> >> > Jodainterest mailing list > >> >> >> > Jodainterest@... > >> >> >> > https://lists.sourceforge.net/lists/listinfo/jodainterest > >> >> >> > > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> >  > >> >> >> Write once. Port to many. > >> >> >> Get the SDK and tools to simplify crossplatform 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/intelappdev > >> >> >> _______________________________________________ > >> >> >> Jodainterest mailing list > >> >> >> Jodainterest@... > >> >> >> https://lists.sourceforge.net/lists/listinfo/jodainterest > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > >  > >> >> > Write once. Port to many. > >> >> > Get the SDK and tools to simplify crossplatform 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/intelappdev > >> >> > _______________________________________________ > >> >> > Jodainterest mailing list > >> >> > Jodainterest@... > >> >> > https://lists.sourceforge.net/lists/listinfo/jodainterest > >> >> > > >> >> > >> >> > >> >> > >> >> >  > >> >> Write once. Port to many. > >> >> Get the SDK and tools to simplify crossplatform 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/intelappdev > >> >> _______________________________________________ > >> >> Jodainterest mailing list > >> >> Jodainterest@... > >> >> https://lists.sourceforge.net/lists/listinfo/jodainterest > >> > > >> > > >> > > >> > > >> > >  > >> > Ridiculously easy VDI. With Citrix VDIinaBox, you don't need a > >> > complex > >> > infrastructure or vast IT resources to deliver seamless, secure access > >> > to > >> > virtual desktops. With this allinone 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/CitrixVDIinabox > >> > _______________________________________________ > >> > Jodainterest mailing list > >> > Jodainterest@... > >> > https://lists.sourceforge.net/lists/listinfo/jodainterest > >> > > >> > >> > >> >  > >> Ridiculously easy VDI. With Citrix VDIinaBox, you don't need a > complex > >> infrastructure or vast IT resources to deliver seamless, secure access > to > >> virtual desktops. With this allinone 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/CitrixVDIinabox > >> _______________________________________________ > >> Jodainterest mailing list > >> Jodainterest@... > >> https://lists.sourceforge.net/lists/listinfo/jodainterest > > > > > > > > >  > > Ridiculously easy VDI. With Citrix VDIinaBox, you don't need a complex > > infrastructure or vast IT resources to deliver seamless, secure access to > > virtual desktops. With this allinone 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/CitrixVDIinabox > > _______________________________________________ > > Jodainterest mailing list > > Jodainterest@... > > https://lists.sourceforge.net/lists/listinfo/jodainterest > > > > >  > Ridiculously easy VDI. With Citrix VDIinaBox, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this allinone 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/CitrixVDIinabox > _______________________________________________ > Jodainterest mailing list > Jodainterest@... > https://lists.sourceforge.net/lists/listinfo/jodainterest > 