TimeZone Problem With DataSourceDateTimeField

[chodges]

Is there anyway to turn OFF the timezone conversion that happens when you have a data source with DateTimeFields? I'm handling the timezone conversion in my own code (long story as to why I need to do it this way) so I really need to get the plain vanilla date that is being sent from my server.

For example my data source has fields like this:

DataSourceDateTimeField startField = new DataSourceDateTimeField("starttime");

DataSourceDateTimeField endField = new DataSourceDateTimeField("endtime");

I tried using the DateUtil.setDefaultDisplayTimezone("00:00"); method but it does not seem to have any effect.

Thanks,

Chris

[Isomorphic]

Can you explain in more depth:

1) what timezone you want rendered

2) what timezone you are sending (and whether you can change this, at all)

3) where you are doing timezone conversion of your own and what you're specifically doing

4) what case you would have expected timeZoneOffset to make a difference and what you expected.

[chodges]

Sure thing.

1) what timezone you want rendered

I don't want any timezone rendered because I'm controlling that in my server side code.


2) what timezone you are sending (and whether you can change this, at all).

The datetime is being sent in the users native timezone but then its transformed to UTC/GMT before being stored in the database.



3) where you are doing timezone conversion of your own and what you're specifically doing

I'm handling the timezone conversion logic in my server logic. I'm using PHP and each user has as part of their profifle the timezone that they're in. So when I'm sending time sensitive data back I'm converting from UTC to the users timezone. I need to do this because some of my customers are bi-coastal and may want to change their timezone accordingly.

4) what case you would have expected timeZoneOffset to make a difference and what you expected.

I would have thought that the TimeZoneOffset method would allow me to control and/or set what the timezone offset would be globally. Maybe another method would be better: a boolean that would make the app timezone agnostic and just take whatever date/time is sent from the server.

--
Chris

[Isomorphic]

1) we're not converting, we're assuming that a time without a timezone offset is GMT (which is what the relevant standards recommend). You can send the timezone offset explicitly

Given 1), the time would then be rendered in local time. If the user changes the system timezone the values would appear differently automatically. If this is what you want, remove your special logic and just transmit the time unambiguously (as a GMT time without offset, or a time in some time zone with an explicit offset).

[chodges]

Okay your suggestions worked as advertised. The SmartGWT controls display the date and time correctly based on the timezone. And of course when saving data the date/time is converted to GMT.

So thats all good.

But here's where I'm having a problem that maybe you can shed some light on: I have a custom calendar and I'm supporting repeating events with my own code. When I create an event that say starts today and repeats everyday until November 30th what happens is that because of DST rules the time ends going back hour (I'm EST time). To better illustrate if I create a calendar event that starts at 5pm and ends at 7pm that starts today the time will be correct until November 1st. Once November 1st rolls around the time goes to 4 and 6pm.

Do you know of anyway to kind of turn off the DST rules so that I can get consistent start and end times when creating repeating events. It appears that the SmartGWT code somewhere is handling this.

thanks.

--
Chris

[Isomorphic]

That sounds like a native browser behavior, and a good reason to deliver times in GMT/UTC to avoid any ambiguity.

[chodges]

Hmmm.... but thats exactly what I don't want to do. When you enter a repeating event in Google Calendar and it is supposed to start at 5pm every Wednesday for the next 6 months GC does not adjust it to start at 4pm when DST changes.

It is smart enough to know that regardless of the DST rules I have an appointment at 5pm regardless.

So thats what I'm trying to duplicate.

[Isomorphic]

SmartGWT has no code for daylight savings handling (and should not). Look over your code for how you generate repeating events and try to understand at what layer daylight savings is causing an offset; it's likely to be in your server code or in how you calculate the offset to send to the browser. It's clearly not SmartGWT but if you think there's something we should do to compensate, let us know.

[chodges]

Okay here's a sample of a repeating event that is getting sent from my server to my client code:

[{"id":"2","starttime":"2009-10-14 21:00:00","endtime":"2009-10-14 00:00:00"
 {"id":"2","starttime":"2009-10-21 21:00:00","endtime":"2009-10-21 00:00:00"
 {"id":"2","starttime":"2009-10-28 21:00:00","endtime":"2009-10-28 00:00:00"
 {"id":"2","starttime":"2009-11-04 21:00:00","endtime":"2009-11-04 00:00:00"
 {"id":"2","starttime":"2009-11-11 21:00:00","endtime":"2009-11-11 00:00:00"
 {"id":"2","starttime":"2009-11-18 21:00:00","endtime":"2009-11-18 00:00:00"
 {"id":"2","starttime":"2009-11-25 21:00:00","endtime":"2009-11-25 00:00:00"

Notice that the start and end times are exactly the same for all dates. This is repeating event that says "5 - 8pm EST every Wednesday between 10/14/2009 and 11/30/2009". And from what you've told me before I should be sending the date/time back in GMT.

Okay now here's what I see after doing a fetch via my DataSource:

cSource.fetchData(_crit,new DSCallback()
{
public void execute(DSResponse response, Object rawData, DSRequest request) {

Record [] r = response.getData();
	
if(r != null && r.length > 0){
	for(int i=0;i<r.length;i++){
System.out.println(r[i].getAttributeAsDate("starttime")+" "+ r[i].getAttributeAsDate("endtime"));
}
}
}

//Here's the output from doing a System.out.println of the dates:

Wed Oct 14 17:00:00 EDT 2009 Tue Oct 13 20:00:00 EDT 2009
Wed Oct 21 17:00:00 EDT 2009 Tue Oct 20 20:00:00 EDT 2009
Wed Oct 28 17:00:00 EDT 2009 Tue Oct 27 20:00:00 EDT 2009
Wed Nov 04 16:00:00 EST 2009 Tue Nov 03 19:00:00 EST 2009
Wed Nov 11 16:00:00 EST 2009 Tue Nov 10 19:00:00 EST 2009
Wed Nov 18 16:00:00 EST 2009 Tue Nov 17 19:00:00 EST 2009
Wed Nov 25 16:00:00 EST 2009 Tue Nov 24 19:00:00 EST 2009

So from my server to my data source you can see that the dates ARE getting converted and moving back an hour once I hit November 1st when DST kicks in.f

[Isomorphic]

Yes, and times expressed in GMT/UTC are actually different times of the day in a timezone that goes through daylight savings time.