Bad date conversion when Collect is in a different time zone from Aggregate

[GoogleCodeExporter]

If Collect is in a different timezone from Aggregate, then incoming date-time 
fields are poorly parsed by Aggregate.

What steps will reproduce the problem?

Suppose that Collect is in +0300 and Aggregate is in UTC (0000).

TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
Date date = DateUtils.parseDateTime("2014-10-05T00:03:05.244+03");
System.out.println(date);

What is the expected output? What do you see instead?
Expected output: "Sat Oct 04 21:03:05 UTC 2014"
Actual output: "Sun Oct 05 21:03:05 UTC 2014"

It seems that only the time is shifted, but since the time shift sometimes 
results in a different day span, the date part should also be shifted.

Here is a proposed solution. The lines 416-426 of DateUtils.java are:

        c.setTimeZone(TimeZone.getDefault());
        long four = c.get(Calendar.HOUR);

        DateFields adjusted = getFields(c.getTime());

        f.hour = adjusted.hour;
        f.minute = adjusted.minute;
        f.second = adjusted.second;
        f.secTicks = adjusted.secTicks;

        return f.check();

I believe they should be:

        c.setTimeZone(TimeZone.getDefault());
        long four = c.get(Calendar.HOUR);

        DateFields adjusted = getFields(c.getTime());

    f.year = adjusted.year;
    f.month = adjusted.month;
    f.day = adjusted.day;
        f.hour = adjusted.hour;
        f.minute = adjusted.minute;
        f.second = adjusted.second;
        f.secTicks = adjusted.secTicks;

        return f.check();

Original issue reported on code.google.com by m.margar...@synergo.gr on 6 Oct 2014 at 6:32

[GoogleCodeExporter]

Then there is also a similar problem in Briefcase, when it does the shift to 
the exporting machine's time zone. If you are exporting in the same time zone 
as Collect, the one missed shift effectively undoes the problem created by the 
other missed shift. But if you are collecting and exporting in different time 
zones, then the "never shifting the date" approach fails in cases where 
midnight is passed in one shift but not the other.

This is a painful problem to fix, because data sitting on the server is 
effectively corrupted (the date-time fields are wrong). Fixing both the server 
and Briefcase at the same time leaves still the corrupted data -- and, worse, 
somebody who was collecting and exporting in the same time zone can see a 
problem suddenly appear only after the fix, for old data sitting on the server.

Original comment by chrislro...@gmail.com on 6 Oct 2014 at 10:19