[stonebranch1]

Excellent. Thank you kindly.

[Isomorphic]

This also includes a fix for calling JSON.encode() statically and passing an encoder as the second argument. That now works as expected.

[Isomorphic]

This is now fixed for tomorrow's 4.1 and 5.0 builds.

[Isomorphic]

We're looking at the best way to address it - we'll update here shortly

[stonebranch1]

Any update on this?

Thanks.

[stonebranch1]

OK, with that resolved (thanks!) we are back to the original issue. If the browser TimeZone is different that what is set using the setDefaultDisplayTimezone, different dates are displayed depending on the 2 TimeZones in use.

In my particular scenario, browser is in Eastern TZ and the code is setting Central TZ ("-05:00") and when I set the 2 dates to May 31 & June 30th and click refresh, I then end up with the 2nd date showing July 1st on the input item and July 2nd on the display label (see attached image 183 and before refresh image 184). Even when setting the date via the picker, the input shows the date I selected and the label shows the next day.

public class Sandbox1 implements EntryPoint {

    @Override
    public void onModuleLoad() {

        // set user to Central TimeZone (make sure this timezone is different than browser).
        DateUtil.setDefaultDisplayTimezone("-05:00");

        final Layout layout = new VLayout(10);

        DataSource dataSource = new DataSource();
        dataSource.setID("xxxDS");
        DataSourceField dateField = new DataSourceField("adate", FieldType.DATE, "Date");
        dataSource.setFields(dateField);
        dataSource.setClientOnly(true);

        final FilterBuilder fb = new FilterBuilder();
        fb.setTopOperatorAppearance(TopOperatorAppearance.RADIO);
        fb.setTopOperator(LogicalOperator.AND);
        fb.setShowModeSwitcher(Boolean.TRUE);
        fb.setDataSource(dataSource);

        final Label label = new Label();

        IButton clear = new IButton("Clear");
        clear.addClickHandler(new ClickHandler() {
            @Override
            public void onClick(ClickEvent event) {
                fb.clearCriteria();
            }
        });

        IButton refresh = new IButton("Refresh");
        refresh.addClickHandler(new ClickHandler() {
            @Override
            public void onClick(ClickEvent event) {
                JSONEncoder encoder = new JSONEncoder();
                encoder.setDateFormat(JSONDateFormat.DATE_CONSTRUCTOR);
                String jsonCriteria = encoder.encode(fb.getCriteria().getJsObj());
                label.setContents("Encoded Criteria: " + jsonCriteria);
                GWT.log("Encoded Criteria: " + jsonCriteria);
                JavaScriptObject jsonObj = JSON.decode(jsonCriteria);
                fb.setCriteria(new AdvancedCriteria(jsonObj));
            }
        });

        layout.addMember(label);
        layout.addMember(fb);
        HLayout buttonLayout = new HLayout(5);
        buttonLayout.addMember(clear);
        buttonLayout.addMember(refresh);
        layout.addMember(buttonLayout);
        layout.draw();

    }

}

Where the serialized 2nd date is: 1404190799999 = Tue Jul 01 00:59:59 EDT 2014

[stonebranch1]

When I changed it as you suggested to the encoder.encode method, I get the expected encoding:

[INFO] [sandbox1] - Encoded Criteria: {
    "_constructor":"AdvancedCriteria", 
    "operator":"and", 
    "criteria":[
        {
            "operator":"betweenInclusive", 
            "fieldName":"adate", 
            "start":new Date(1401512400000), 
            "end":new Date(1404190799999)
        }
    ]
}

[Isomorphic]

Just use the instance method jsonEncoder.encode() instead of using the JSON.encode() class method.

Note that the class method should *also* work, and we'll see if we can reproduce the issue you report.

[stonebranch1]

Sorry to keep troubling you with this....

Just want to check if this is what you had in mind:

public void onClick(ClickEvent event) {
    JSONEncoder encoder = new JSONEncoder();
    encoder.setDateFormat(JSONDateFormat.DATE_CONSTRUCTOR);
    String jsonCriteria = JSON.encode(fb.getCriteria().getJsObj(), encoder);
    label.setContents("Criteria: " + jsonCriteria);
    GWT.log("Criteria: " + jsonCriteria);
    JavaScriptObject jsonObj = JSON.decode(jsonCriteria);
    fb.setCriteria(new AdvancedCriteria(jsonObj));
}

Which still gives me the String values and not Date objects as I expected.

[INFO] [sandbox1] - Criteria: {
    "_constructor":"AdvancedCriteria", 
    "operator":"and", 
    "criteria":[
        {
            "operator":"betweenInclusive", 
            "fieldName":"adate", 
            "start":"2014-05-31T05:00:00.000", 
            "end":"2014-06-14T04:59:59.999"
        }
    ]
}

[Isomorphic]

to/fromJSON does what it says - if you want JSON, you can use them. The problem is, JSON can't automatically round-trip dates without adding some additional processing of your own.

We plan to put a note in the docs so that people who are not familiar with this limitation of JSON don't head down this path.

In the meantime, the setting to allow round-tripping of dates is prominently mentioned right on JSONEncoder.encode() - setDateFormat().

[stonebranch1]

So the to/from JSON methods should not be used then?

I am trying to figure out how to do it using the encoder, can you provide any tips or a simple example?

[Isomorphic]

What's happening is that to/fromJSON cannot automatically round-trip date values, because the JSON format itself has no ability to represent date values.

Take a look at JSONEncoder as suggested in the main AdvancedCriteria docs - it supports a special not-quite-JSON format that can round-trip date values successfully.

[stonebranch1]

Here is a sample which shows even more of a problem in that the restore of the filter doesn't even show the proper values at all. I don't have that problem which maybe due to the fact that I have parsing/formatting setup in my real application where as this sample is just using the defaults.

Anyway, select the between operator and select two explicit dates and then click the "Refresh" button. In my environment the Dates flip back (the problem I don't see in my application) and one of the dates (depending on your timezone) will show a different value in the input field from the display field (the problem I do see in my real application). See attached image.

public class Sandbox1 implements EntryPoint {

    @Override
    public void onModuleLoad() {
        // set user to Central TimeZone (make sure this timezone is different than browser).
        DateUtil.setDefaultDisplayTimezone("-05:00");

        final Layout layout = new VLayout(10);

        DataSource dataSource = new DataSource();
        dataSource.setID("xxxDS");
        DataSourceField dateField = new DataSourceField("adate", FieldType.DATE, "Date");
        dataSource.setFields(dateField);
        dataSource.setClientOnly(true);

        final FilterBuilder fb = new FilterBuilder();
        fb.setTopOperatorAppearance(TopOperatorAppearance.RADIO);
        fb.setTopOperator(LogicalOperator.AND);
        fb.setShowModeSwitcher(Boolean.TRUE);
        fb.setDataSource(dataSource);

        final Label label = new Label();

        IButton clear = new IButton("Clear");
        clear.addClickHandler(new ClickHandler() {
            @Override
            public void onClick(ClickEvent event) {
                fb.clearCriteria();
            }
        });

        IButton refresh = new IButton("Refresh");
        refresh.addClickHandler(new ClickHandler() {
            @Override
            public void onClick(ClickEvent event) {
                AdvancedCriteria ac = fb.getCriteria();
                if (ac == null) return;
                String criteria = ac.toJSON();
                label.setContents("Criteria: " + criteria);
                GWT.log("Criteria: " + criteria);
                fb.setCriteria(AdvancedCriteria.fromJSON(criteria));
            }
        });

        layout.addMember(label);
        layout.addMember(fb);
        HLayout buttonLayout = new HLayout(5);
        buttonLayout.addMember(clear);
        buttonLayout.addMember(refresh);
        layout.addMember(buttonLayout);
        layout.draw();

    }

}

[Isomorphic]

Your system for serializing date/datetime values as Strings in an attempt to avoid timezone shifts is what's unnecessary. Including whatever server-side code you've put in place to re-convert back to Dates. This is already handled properly by the framework.

That said, if you can show an issue with valid usage in a standalone test case, we'll of course correct it.

[stonebranch1]

The only code we have for dealing with TimeZones is basically setting the default display time zone via setDefaultDisplayTimezone so we are in fact calling that method and then the only other thing we do on the client is parse/format DateTime fields to show the TimeZone.

So I am not sure what unnecessary approach you are referring to?

Look at the screen images and view the filter. That is just a FilterBuilder using a Date field where the setDefaultDisplayTimezone has been set to a TimeZone that is different from the browser TimeZone and viola different dates appear. The ONLY code of ours in play for the Date field is in fact the call we made to setDefaultDisplayTimezone.

I will create a simple code to reproduce it for you that wil show just calling setDefaultDisplayTimezone to a different TimeZone of the browser causes the FilterBuilder Between operator of a Date to show incorrectly on the UI.