Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    LocalTime gets offset in client

    Hi, i have a question re. LocalTime. In my world, it's a time without any concept of offset or zone, which is what i need in a particular use case. So i thought i'd try to send that from the server.
    However, it seems that it still gets offset when transmitted.

    I have a SpringBean as a datasource, it returns a "ScheduleSettings" object you can see below.

    0. Debugger when creating the object to return:
    Click image for larger version  Name:	Screen Shot 2021-08-18 at 13.17.55.png Views:	0 Size:	23.9 KB ID:	266210


    1. The class i return from my fetch method:
    Code:
    @Getter
    @AllArgsConstructor
    public class ScheduleSettings {
        private final LocalTime defStart;
        private final LocalTime defEnd;
    .....other fields
    }
    2. This is what is sent in the Data field over the network:
    {defStart:new Date(25200000),defEnd:new Date(50400000)....more stuff.}


    3. When i then try to get the parameter out, it's a Date that has been offset by zone just like anything else:

    Code:
    if (resp.getStatus() == DSResponse.STATUS_SUCCESS) {
                    Map dataAsMap = resp.getDataAsMap();
                    for (Object o1 : dataAsMap.keySet()) {
                        GWT.log(o1 + " -> " + dataAsMap.get(o1));
                    }
    gives: defStart -> Thu Jan 01 08:00:00 GMT+100 1970. As you can see it's been offset by one hour from UTC (where my browser is at)

    ---

    I think that localdate/time should not deal with timezone offsets at all since that's the way they should work. Or am i missing something?

    Pointers appreciated.
    Attached Files

    #2
    If you want a time with no concept of a date, the DataSource field needs to be declared as type "time". It won't happen just from using a particular Java flavor of Date object.

    As far as how "time" values are handled, see the Date and Time Format and Storage overview

    Fields of type time are time values in the absence of a day, such as the beginning of the workday (9:00). In the browser, values for "time" fields are stored as Date objects with the time in browser local time. The date information has no meaning and only the time information is displayed to the user.

    Comment


      #3
      Right. Well, i'm using an operation of type "custom" in this particular case, so there's no time field declared in the .ds.xml. The custom method returns a java object with the parameter above, which gets put in the data field of the dsresponse by smartgwt. It then apparently gets transmitted as a date object after having its timezone shifted server-side as i explain above, which results in the Date object that is in the dsresponse client-side has it's value shifted from utc to the browser local timezone.
      I would have thought that since the field is a LocalTime, it would be treated as a "time" field. I'll guess i'll think to see what i can do.

      Comment


        #4
        I did some experimenting and found something peculiar. The reason for this whole thing is that i'm migrating some old code, and I discovered that here i use the JodaTime LocalTime classes for some reason where in other parts of the system it's always the java.time.LocalTime When doing a small test i could see why:

        I have a datasource with a custom fetch operationid:
        Code:
        <operationBinding operationType="fetch" operationId="info"> <serverMethod>fetchInfo</serverMethod> </operationBinding>
        The relevant spring bean code. As you can see, i'm just putting some parameters with the two LocalTime classes:
        Code:
        DSResponse resp = new DSResponse();
        java.time.LocalTime local = java.time.LocalTime.of(10, 45);
        LocalTime joda = LocalTime.fromMillisOfDay(local.toSecondOfDay() * 1000);
        System.out.println("LocalTime: " + local);
        System.out.println("Joda LocalTime: " + joda);
        resp.setParameter("localtime", local);
        resp.setParameter("jodatime", joda);
        
        System.out.println("LocalTime: " + local);
        System.out.println("Joda LocalTime: " + joda);
        System.out server-side:
        LocalTime: 10:45
        Joda LocalTime: 10:45:00.000
        On the network:
        localtime: new Date(38700000)
        jodatime: isc.DateUtil.parseServerTime(10,45,0,0)
        Client code in the callbackhandler:
        Code:
        GWT.log("local: " + resp.getAttribute("localtime"));
        GWT.log("joda: " + resp.getAttribute("jodatime"));
        
        GWT.log("local date: " + resp.getAttributeAsDate("localtime"));
        GWT.log("joda date: " + resp.getAttributeAsDate("jodatime"));
        client side gwt.log output:
        local: Thu Jan 01 1970 11:45:00 GMT+0100 (Central European Standard Time)
        joda: Sun Dec 31 1899 10:45:00 GMT+0100 (Central European Standard Time)

        local date: Thu Jan 01 11:45:00 GMT+100 1970
        joda date: Sun Dec 31 10:45:00 GMT+100.23333333333333428
        As you can see, they are one hour apart in the client. if i use the jodatime class it behaves as i would deem desirable i.e. that the resulting date has the same value as the LocalTime on the server.

        Isn't a bit strange that the two LocalTime objects, which both are Times without timezone information, are handled differently?
        Last edited by mathias; 19 Aug 2021, 01:05.

        Comment

        Working...
        X