TimeItem jumps by 1 hour in non-GMT zones

[atomatom]

I'm using the latest nightly EE eval.

Since the clocks changed for daylight savings time, I have been getting this bug where times entered into a TimeItem jump back an hour after they are saved on the server. So, I try and save 2pm, and the TimeItem then jumps to 1pm after saving.

Here is what I have observed in my DMI-called methods on the server.

Since a field of type "time" only contains the time (say 2pm) it is stored as a java.util.Date at 1/1/1970 14:00 UTC. All fine.

Once daylight savings goes away, this time is stored with an offset of 1 hour, so 2pm is now stored at 1/1/1970 13:00 UTC. Is this correct?

I'll try and generate a test case that demonstrates this.

[atomatom]

Further debugging results. I've tested this under Firefox on Ubuntu and IE in Windows XP. Both in developer mode and compiled.

I created a simple form with a TimeItem in it. I enter 12:01 in the time and I use a changed handler to output the contents of the form item:

 time = Tue Apr 12 12:01:00 PDT 2011 
 t=1302634860000

I then save the result. The RPC request (from the SC console) says

 "time":"19:01:00"

The response from the server after updating the field is

 time:new Date(68460000)

which is the same time 19:01 but at Jan 1/1/1970. The client code then updates my TimeItem to 11:01 (which is the Date applied with Daylight savings).

other information:

datasource.xml definition

<field name="time" type="time" hidden="false" />

public MyJavaClass {
     Date time;

     //standard bean get/set methods
}

---------------

So, my question then is why does TimeItem store the time in a Date instance on the current day instead of on Jan 1/1/1970? Is this a bug?

[dencel]

You can try DateUtil.setAdjustForDST(false) to get consistent behaviour.

[atomatom]

thanks for the suggestoin dencel. that does indeed fix it - but unfortunately using that fix means all the other dates (ie, datetime) are broken. :/

on the upside, the bug is only observed during 6 months of the year.

[dencel]

I am sending all timestamps from the server using ISO8601 standard and +0 offset. I figured out there are still a lot of issues using time notations (for example FieldType.TIME assumes GMT+0). This solves all my problems on the client and server side.

[atomatom]

Thanks dencel. I've been mulling over how to easily deal with this.

Your suggestion is certainly an approach I've used before and it might be the best thing to do here. Rather an annoying amount of coding though. :/ Clearly, you should never start a project during daylight savings. :)

I'd really rather be able to tell SmartClient to render all TimeItem (rather any type="time") without DST adjustments (rather than every single Date).

[atomatom]

An unpleasant, but quick, fix is to change the field type to datetime in the datasource definition.

Really though, I need to come back and look at how my dates are stored on the server.

It is still my belief that this is a bug in SmartClient:

TimeItem stores the time in a Date instance on the current day instead of on Jan 1/1/1970. This causes a bug unless the current day is in Daylight savings time.

[atomatom]

Unless there's some objection/clarification from Isomorphic, I'm going to file this as a bug.

[Isomorphic]

We've made a change which should resolve this. Please try the next nightly build and let us know if you still have issues.