Strange behavior with rounding and timezone

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Strange behavior with rounding and timezone

Shay Banon
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strange behavior with rounding and timezone

jodastephen
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 <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strange behavior with rounding and timezone

Shay Banon
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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strange behavior with rounding and timezone

Shay Banon
Anyone?

On Fri, Dec 23, 2011 at 1:17 AM, Shay Banon <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strange behavior with rounding and timezone

jodastephen
In reply to this post by Shay Banon
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>> > [hidden email]
>> > 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strange behavior with rounding and timezone

Shay Banon
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>> > [hidden email]
>> > 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strange behavior with rounding and timezone

jodastephen
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>> > <[hidden email]>
>> > 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 <[hidden email]> 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
>> >> > [hidden email]
>> >> > 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
>> >> [hidden email]
>> >> 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
>> > [hidden email]
>> > 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strange behavior with rounding and timezone

Shay Banon
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>> > <[hidden email]>
>> > 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 <[hidden email]> 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
>> >> > [hidden email]
>> >> > 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
>> >> [hidden email]
>> >> 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
>> > [hidden email]
>> > 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strange behavior with rounding and timezone

jodastephen
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>> > <[hidden email]>
>> > 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 <[hidden email]> 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
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]> 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
>> >> >> > [hidden email]
>> >> >> > 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
>> >> >> [hidden email]
>> >> >> 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
>> >> > [hidden email]
>> >> > 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
>> >> [hidden email]
>> >> 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
>> > [hidden email]
>> > 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strange behavior with rounding and timezone

Shay Banon
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>> > <[hidden email]>
>> > 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 <[hidden email]> 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
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]> 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
>> >> >> > [hidden email]
>> >> >> > 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
>> >> >> [hidden email]
>> >> >> 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
>> >> > [hidden email]
>> >> > 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
>> >> [hidden email]
>> >> 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
>> > [hidden email]
>> > 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strange behavior with rounding and timezone

jodastephen
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>> > <[hidden email]>
>> > 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 <[hidden email]> 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
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]> 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
>> >> >> > <[hidden email]>
>> >> >> > 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 <[hidden email]> 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
>> >> >> >> > [hidden email]
>> >> >> >> > 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
>> >> >> >> [hidden email]
>> >> >> >> 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
>> >> >> > [hidden email]
>> >> >> > 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
>> >> >> [hidden email]
>> >> >> 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
>> >> > [hidden email]
>> >> > 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
>> >> [hidden email]
>> >> 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
>> > [hidden email]
>> > 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strange behavior with rounding and timezone

Shay Banon
First, thanks for sticking with me :). I think I might need to go down the custom code route, wanted to verify if my logic is sound. Rounding based on zone is done in ZoneChrono, basically, this:

            if (iTimeField) {
                int offset = getOffsetToAdd(instant);
                instant = iField.roundFloor(instant + offset);
                return instant - offset;
            } else {
                long localInstant = iZone.convertUTCToLocal(instant);
                localInstant = iField.roundFloor(localInstant);
                return iZone.convertLocalToUTC(localInstant, false, instant);
            }

But, this does not work well in my case. If its iTimeFIeld, then it will return the UTC millis, but if not, then there is no need to convertLocalToUTC, since its already in UTC millis because of the "bigger" rounding. Is that correct?

On Fri, Dec 30, 2011 at 1:13 AM, Stephen Colebourne <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>> > <[hidden email]>
>> > 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 <[hidden email]> 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
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]> 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
>> >> >> > <[hidden email]>
>> >> >> > 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 <[hidden email]> 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
>> >> >> >> > [hidden email]
>> >> >> >> > 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
>> >> >> >> [hidden email]
>> >> >> >> 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
>> >> >> > [hidden email]
>> >> >> > 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
>> >> >> [hidden email]
>> >> >> 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
>> >> > [hidden email]
>> >> > 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
>> >> [hidden email]
>> >> 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
>> > [hidden email]
>> > 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strange behavior with rounding and timezone

jodastephen
I suspect that your use case is a little specific for Joda-Time, but
hopefully the convertUTCToLocal() and similar methods will help you
write the custom code.

The iTimeField code below is an optimisation. If the field is smaller
than a day, then there is no need to take time-zones into account in
the same way. (Rounding to the nearest minute is only ever a small
change)

Stephen


On 30 December 2011 12:52, Shay Banon <[hidden email]> wrote:

> First, thanks for sticking with me :). I think I might need to go down the
> custom code route, wanted to verify if my logic is sound. Rounding based on
> zone is done in ZoneChrono, basically, this:
>
>             if (iTimeField) {
>                 int offset = getOffsetToAdd(instant);
>                 instant = iField.roundFloor(instant + offset);
>                 return instant - offset;
>             } else {
>                 long localInstant = iZone.convertUTCToLocal(instant);
>                 localInstant = iField.roundFloor(localInstant);
>                 return iZone.convertLocalToUTC(localInstant, false,
> instant);
>             }
>
> But, this does not work well in my case. If its iTimeFIeld, then it will
> return the UTC millis, but if not, then there is no need to
> convertLocalToUTC, since its already in UTC millis because of the "bigger"
> rounding. Is that correct?
>
> On Fri, Dec 30, 2011 at 1:13 AM, Stephen Colebourne <[hidden email]>
> wrote:
>>
>> 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 <[hidden email]> 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
>> > <[hidden email]>
>> > 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 <[hidden email]> 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
>> >> > <[hidden email]>
>> >> > 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 <[hidden email]> 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
>> >> >> > <[hidden email]>
>> >> >> > 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 <[hidden email]> 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
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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 <[hidden email]>
>> >> >> >> >> 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
>> >> >> >> >> > [hidden email]
>> >> >> >> >> > 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
>> >> >> >> >> [hidden email]
>> >> >> >> >> 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
>> >> >> >> > [hidden email]
>> >> >> >> > 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
>> >> >> >> [hidden email]
>> >> >> >> 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
>> >> >> > [hidden email]
>> >> >> > 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
>> >> >> [hidden email]
>> >> >> 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
>> >> > [hidden email]
>> >> > 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
>> >> [hidden email]
>> >> 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
>> > [hidden email]
>> > 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Strange behavior with rounding and timezone

Shay Banon
I did not mean to have this in Joda, I can write something that does it, just wanted to know if my logic where if its not "iTimeField" (bigger rounding), then:

long localInstant = iZone.convertUTCToLocal(instant);
localInstant = iField.roundCeiling(localInstant);
<-- here, localInstance is actually UTC millis, so we can use that as UTC millis and not call the following:
return iZone.convertLocalToUTC(localInstant, false, instant);

When it is iTimeField, then the double conversion will keep it in UTC millis.


On Fri, Dec 30, 2011 at 3:02 PM, Stephen Colebourne <[hidden email]> wrote:
I suspect that your use case is a little specific for Joda-Time, but
hopefully the convertUTCToLocal() and similar methods will help you
write the custom code.

The iTimeField code below is an optimisation. If the field is smaller
than a day, then there is no need to take time-zones into account in
the same way. (Rounding to the nearest minute is only ever a small
change)

Stephen


On 30 December 2011 12:52, Shay Banon <[hidden email]> wrote:
> First, thanks for sticking with me :). I think I might need to go down the
> custom code route, wanted to verify if my logic is sound. Rounding based on
> zone is done in ZoneChrono, basically, this:
>
>             if (iTimeField) {
>                 int offset = getOffsetToAdd(instant);
>                 instant = iField.roundFloor(instant + offset);
>                 return instant - offset;
>             } else {
>                 long localInstant = iZone.convertUTCToLocal(instant);
>                 localInstant = iField.roundFloor(localInstant);
>                 return iZone.convertLocalToUTC(localInstant, false,
> instant);
>             }
>
> But, this does not work well in my case. If its iTimeFIeld, then it will
> return the UTC millis, but if not, then there is no need to
> convertLocalToUTC, since its already in UTC millis because of the "bigger"
> rounding. Is that correct?

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Loading...