Perhaps DateTimeZone.convertUTCToLocal(utcMillis) might be the method you want?
Or, MutableDateTime.setZoneRetainMillis(UTC) ?
both will effectively get the "local millis".
Stephen
On 29 December 2011 18:23, Shay Banon <kim...@gmail.com> wrote:
> 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 <scolebou...@joda.org>
> wrote:
>>
>> 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
>
>
>
> ------------------------------------------------------------------------------
> 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
