Timestamps always adjusted for DST

[jpappalardo]

I have called the following 2 lines of code in our application:

        DateUtil.setDefaultDisplayTimezone("+00:00");
        DateUtil.setAdjustForDST(false);

Although dates are displayed in ZULU time, they are still DST adjusted. Is there another means for disabling DST?

SmartClient Version: v8.2p_2012-10-03/PowerEdition Deployment (built 2012-10-03)

[Isomorphic]

These settings look correct for displaying datetime type fields (or time type fields) in zulu time (with no DST adjustment).

To comment further we'll need to see some example code and have a clear picture of the use case that is failing for you. There are a number of variables that may be impacting this -- the type of the field (date vs time vs datetime), where the data is coming from, how its being displayed, etc -- so without more information it's impossible to tell if we're looking at a misunderstanding within the application code, or a case of the framework not behaving as expected.

Note that we have some fairly comprehensive docs on date and time format and display that are worth looking over if you haven't already -- see here

Thanks
Isomorphic Software

[jpappalardo]

I really need some help on this issue. Locale is messing up our dates and times in a few places. One place is probably my fault. But before I get there we have a StaticTextItem that is displaying a date that is persisted as :

sched_takeoff_time | 2013-01-01 00:00:00

and it the static text item is displayed as Dec 31 2012 19:00

That same value is displayed in an editing form that uses this custom class for splitting dates and times

This code results in displaying the value as 12-31-2012 00:00

If use the exact same persisted value in a list grid it displays as expected as 1-1-2013 00:00

I can feel my hairs turn grey as I try to understand why dates get treated differently in different places. Any help would be greatly appreciated.


*****EDIT******
Upon further evaluation the date object passed in to the showValueHandler is 12-31-2012 00:00
So it appears to me that somehow the dynamic form itself is corrupting the value being passed in

[Isomorphic]

We're taking a look at your example - we'll let you know what we find.

Regards
Isomorphic Software

[Isomorphic]

In a nutshell, you need to make use of our "logical date" vs "logical time" vs "datetime" distinctions in order to have things render correctly.

Your date/time component consists of a logical date editor and a logical time editor, and ultimately outputs a datetime.
We have utility methods on the DateUtil class that handle taking a datetime and splitting it into a logical date / logical time and vice versa.
If you make use of these in your methods to split / combine the datetime, your editor will display the expected values. Here's a snippet showing what we mean:

        @SuppressWarnings("deprecated")
        private Date combineFields(DynamicForm form) {
            Date dateDate = (Date)form.getValue("dateOnly");
            Date timeDate = (Date)form.getValue("timeOnly");
            
            if(dateDate != null && timeDate != null) {
                if(form.getValueAsString("dateOnly").isEmpty() && form.getValueAsString("timeOnly").isEmpty()) {
                    return null;
                }
                return DateUtil.combineLogicalDateAndTime(dateDate, timeDate);
            } else {
                return null;
            }
        }

        @SuppressWarnings("deprecated")
        private void splitFields(Date date, CanvasItem canvasItem) {
            if(getCanvas() == null) {
                return;
            }
            DynamicForm form = (DynamicForm)canvasItem.getCanvas();
            // as passed in this is a datetime - we need to convert to a "logical date" and
            // a "logical time"
            Date logicalDate = DateUtil.getLogicalDateOnly(date);
            Date logicalTime = DateUtil.getLogicalTimeOnly(date);
            if(date != null) {
                form.setValue("dateOnly", logicalDate);
                form.setValue("timeOnly", logicalTime);
                canvasItem.storeValue(date);
            }
            else {
                form.clearValue("dateOnly");
                form.clearValue("timeOnly");
            }
        }

In general the thing that makes this tricky is that there's quite a semantic difference between a logical date and a datetime. A datetime is a specific moment. When formatted for display, the timezone is important. By default we display datetimes in browser local time, though you can customize this (as you have done). We represent these as JavaScript dates (which are available as Java dates in SmartGWT). Depending on your timezone settings the result of a call to 'getFullYear()' / 'getMonth()' / 'getDate()' etc may or may not match what is displayed to the user.
By contrast, a logical date is not a specific moment - it is a calendar date and has no timezone information. These are also represented within the framework code as JavaScript date instances, but the time has been set to a value that is essentially arbitrary (12 noon, browser local time) in order to ensure consistent display across timezones, etc.

When formatting logical dates or datetimes for display, the system handles showing the correct values for fields based on their specified field type.
If you have to perform formatting yourself, you can use the standard formatting functions in the DateUtil class to ensure you get back a string that has been adjusted for the specified timezone, etc.

The date and time docs we referred you to earlier should help make sense of this - but if you have further questions please let us know

Thanks
Isomorphic Software

[jpappalardo]

Are these API methods in SmartGWT 3.1? I do not see them in 3.0.

[Isomorphic]

Ah - yes they are. They've been present a long time (along with some documentation clearing up this confusion), but were never ported over to the 3.0p branch. No wonder you were having problems.

Sorry for the confusion we'll port these across to the 3.0p branch today.

[jpappalardo]

I appreciate your moving that part of the API over for me.

At this point following the documentation, and using the newly provided methods I have gotten much closer. I have figured out how to get dates in a static text item to appear as persisted in utc time. My custom form item now displays the persisted value correctly. When editing using my custom form item, you no longer observe the time values getting offset by locale automatically.

However, when I save the form it sends the value adjusted in by locale. Hence Entering Jan 1 2013 00:00, goes to the server as Jan 1 2013 05:00. I am guessing there is one more piece of the puzzle that I am missing?

[Isomorphic]

Our dataSource serialization should handle correctly serializing datetimes such that they have the correct UTC date and time values.

To figure out what's going wrong for you, we'd need to know what sort of dataSource you're using and in what sense the date is incorrect. Is this a built-in "sql" dataSource, a dataSource with custom server operations, or something else (a RESTDataSource, etc)?
When you say the date being sent to the server is "Jan 1 2013 05:00", are you referring to the serialized value in the request being an incorrect string [If so, what are you seeing?], or are you referring to another symptom - some server-side Java code within your DataSource implementation picking up the Date object with an unexpected value, or something else (incorrect round trip when saving / reloading values or similar).

[jpappalardo]

Let me walk you through and provide some screenshots from running in debug mode.

I Enter a value Jan 1 2013 and 00:00
When combineFields executes, the underlying objects have the correct date and time but show they are using EST. The result of DateUtil.combineLogicalDateAndTime is also in EST.

So when the value is serialized it is transmitted as UTC and hence the hour moves by 5. It is the schedTakeoffTime field in the attached add.jpg.

It appears to me the issue is strictly client side, but to be thorough I am using a custom extension of JPA2DataSource. The request is also transformed via a DataSource DMI. This particular field is never touched by any of the aforementioned code, and is ultimately handled directly by JPA2DataSource.

[Isomorphic]

The behavior your describing sounds incorrect -- the specified display offset of zero should basically be causing the datetime to be transmitted with UTC time set to match the display time the user saw.
We're taking a look to see if we can reproduce this same effect. We'll let you know what we find

Thanks
Isomorphic Software

[Isomorphic]

We've looked into this and there was indeed a bug in these APIs.
This has now been resolved. Please try picking up the next nightly build (dated October 19 or greater) and let us know if you continue to have trouble with this

Regards
Isomorphic Software

[jpappalardo]

To be sure it looks close. I enter a value of Jan 1 2013 00:00 and that's what goes across the wire and is persisted.

The summary form containing the value in a StaticTextItem displays the value exactly as persisted. However, in the editing form where my SplitDateTimeItem is used, the value is presented as Dec 31 2012 00:00. Using debug mode I provide another screen shot of the date passed into splitFields along with the results of your API methods to split the date.

To demonstrate that this issue is unique to the value passed into the form item, I provide a second screenshot. I have a ListGrid that displays the values, but editing is done in a popup with a form that contains the SplitDateTimeItem. I enter a value of Jan 1 2013 00:00, persist, and see the value in the ListGrid as expected. However when invoking editing via the popup, the value in the form is displayed as Dec 31 2012 00:00.

For the sake of sanity I provide the SplitDateTimeItem in its present form:


I provide another screenshot of the value in the debugger retrieved via showValueEvent.getDataValue(). Just to verify that I am not somehow doing something to cause this value to be modified myself.

[Isomorphic]

We're taking another look

Regards
Isomorphic Software

[Isomorphic]

We have made a change which we believe will address this. Please try the next nightly build and let us know how it goes

Regards
Isomorphic Software