Time fields in ListGrid, timezone and formatting

[alex430]

Hi Isomorphic!

Setting Time.setNormalDisplayFormat('toShortPadded24HourTime') seems to be ignored in Listgrids, okey thats a minor issue cause I can work around it with timeFormatter in the field definition.

Datetime fields are working now correctly for me, but time fields gets recalculated with timezone before sent to server, even with Time.adjustForDST = false and
Time.setDefaultDisplayTimezone('+00:00').

Here timezone +1, with daylight saving +2 now, I can increase the time in the form of my testapp just by clicking the save button.


I'm using:
SC_SNAPSHOT-2011-06-17

I've tested this with several actual browsers, but always with the same effect.



My testapp can be found here:
https://88.151.78.166/sc-test/time-fields.php

Time.setNormalDisplayFormat('toShortPadded24HourTime');
Time.setShortDisplayFormat('toShortPadded24HourTime');
Time.adjustForDST = false;
Time.setDefaultDisplayTimezone('+00:00');

Date.setShortDatetimeDisplayFormat('toEuropeanShortDateTime');
Date.setShortDisplayFormat('toEuropeanShortDate');
Date.setDefaultDateSeparator('.');
Date.setInputFormat("DMY");



isc.RestDataSource.create({
    ID:"testDS",

    operationBindings: [
        {
            operationType:"fetch",
            dataProtocol:"postParams",
            dataURL:"/sc-test/rest.php?op=fetch"
        },
        {
            operationType:"add",
            dataProtocol:"postParams",
            dataURL:"/sc-test/rest.php?op=add"
        },
        {
            operationType:"remove",
            dataProtocol:"postParams",
            dataURL:"/sc-test/rest.php?op=remove"
        },
        {
            operationType:"update",
            dataProtocol:"postParams",
            dataURL:"/sc-test/rest.php?op=update"
        }
    ],
    dataFormat:"json",
    dataURLbase: "/sc-test/rest.php",
    fields:[
        {
            title: "ID",
            name:"id",
            primaryKey: true
        },
        {
            title: "Datetime 1",
            name: "dt1",
            canEdit: false,
            type: "datetime"
        },
        {
            title: "Datetime 2",
            name: "dt2",
            type: "datetime"
        },
        {
            title: "Time 1",
            canEdit: true,

            name: "time1",
            type: "time"
        }

    ]
});


isc.VLayout.create({
    width: 850,
    height: 500,
    members: [
        isc.ListGrid.create({
            width: "100%",
            height: 150,
            dataSource: "testDS",
            autoFetchData: true,

            selectionChanged: function(record, state) {
                DetailForm.editRecord(record);
            }
        }),
        isc.DynamicForm.create({
            ID: "DetailForm",
            dataSource: "testDS",
            margin: 20
        }),

        isc.IButton.create({
            title: 'save',
            click: function() {
               DetailForm.saveData();
            }
        })
    ]
})

Regards,
Alex

[atomatom]

this is messing me up too. something happened somewhere after june 6th. builds on june 6th and before are fine.

[Isomorphic]

We believe this issue has now been resolved. Please try the next nightly build and let us know if you continue to have problems with it.

Thanks
Isomorphic Software

[alex430]

Hi!

Sorry, but its the same as before.

Regards,
Alex

[Isomorphic]

Once you've installed the new build, run a GWT compile and clear your browser cache, then retest.

[alex430]

Cleared the cache (again), but it works as before.
I'm using the LGPL Edition, so I think compiling is moot.


Regards,
Alex

[Isomorphic]

GWT compile matters regardless.

You may also be building from SVN, that's not the latest code, smartclient.com/builds is.

[atomatom]

Correction. I'm still having issues as well.

[atomatom]

This is still causing me a fair bit of pain. This is with the 6/30 nightly.

I think I've narrowed down my problem at least a bit.

TimeItem javadoc says:

Values entered by the user are stored as JavaScript Date objects in GMT/UTC time regardless of the local time zone.

The TimeItem docs state that "time" is stored as GMT - great. Now, when the server serializes a Date object to send to the client, it seems to be converting the time on the way back to the local timezone.

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

I've checked the following:

* Time is stored as UTC value ( 9 AM UTC ) - *edit* - this does not appear correct. time is stored as 9 AM Local time
* Time is sent to server ( as "09:00" Date(32400000) ) - shown in Java Console
* Server gets a UTC date ( 9 AM UTC ) - shown in Java Console
* Server sends back UTC date ( 9 AM UTC ) - shown in Java Consile
* Client receives back ( 9 AM *LOCAL TIME* Date(-25200000) (timezone=PST) ) - argh! - shown in SC Console


The ListGrid actually shows the correct time, 9AM. But I was under the impression that a time was stored as UTC. Certainly, it seems to send a UTC date - but the response it gets back is not UTC but still displays ok.

So, I think this is the bug: the documentation says that "time" is stored as UTC, it does not appear to be stored as UTC on the client.

Timezone bugs make me cry.... :/

(Note: I have some date format code, and it also shows the Date value being passed into my client-side date as being 9AM Local Time, not UTC)

[atomatom]

Just checking with older versions. This behavior seems to be the same. Need to debug more to try and narrow this down.

[atomatom]

I've managed to hack my way around this. I can confirm that the time is being stored in LOCAL - not UTC time. I verified this by looking at the result set and grabbing the time value out, eg,

isc_ResultSet_13.localData[0].startTime.getTime()

which returned -25200000 (9am PST) instead of 32400000 (9 am UTC)

So my workaround is to sometimes use timezone conversion and sometime not. It seems to be working(*), but I think the javadoc is wrong - time is stored in Local zone, not UTC.

(* but feels bloody awful and hackish)

[Isomorphic]

You're correct, time values are stored as local time on the epoch start date (Jan 1 1970) and the docs have been fixed to reflect this. If you believe there's some other issue or inconvenience, please post a new thread about that.