Announcement

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

    Calendar - Time.setDefaultDisplayTimezone('+00:00'); issue

    SmartClient Version: v10.0p_2014-11-16/Pro Deployment (built 2014-11-16)

    CHROME - Version 39.0.2171.95 (64-bit)

    Link to our Calendar problem:
    http://com.moogle.at/calendar_timezone_bug/

    When i set Time.setDefaultDisplayTimezone('+00:00');

    The created Calendar events are displayed wrong with this DefaultDisplayTimezone.

    Our standard Timezone in our Country is +01:00
    Anyway we want to calculate with +00:00
    But then the Output of the Calendar is Displayed wrong for 1 hour.

    Shouldn't the Calendar automatically display the Output correctly in relation to the DefaultDisplayTimezone?

    So if you try to create an Calendar event in the Calendar provided by our Link you'll see that the created time isn't the same as the displayed time in the Calendar.

    We wonder how this can be fixed

    Hope you can help us!
    Looking forward to your response
    Thaddäus

    #2
    still having timezone problems

    still having problems with the timezone issue..

    would be great if someone has a solution idea

    Comment


      #3
      Any news regarding this topic?

      In the last project I kicked out all smartclient calendar widgets cause of the timezone issues, which is a shame IMHO.

      Comment


        #4
        We have automated tests that show no issues in this area.

        If you think there's a bug in the framework, we'll need to see a standalone, minimal test case the shows the problem.

        Comment


          #5
          Hi Isomorphic!

          http://com.moogle.at/calendar_timezone_bug/ is a almost standalone, minimal test case, I think.

          If you look at the attached screenshot, you can see the day starts at 01:00am. (EDIT this was with SC Version 9, now its shown as 12:00am or 12:00vormittag which is a ambiguous in german)
          I guess thats cause I'm at GMT+1 here, I don't know how it looks elsewhere.

          There are some other strange behaviors when editing events of a databound calendar object.

          I will try to create a simple example which (hopefully) shows the problem.



          EDIT:

          1. I found out that http://com.moogle.at/calendar_timezone_bug/ was linked to a version 9 /isomorphic folder, its now corrected to v10.0p_2014-11-16.
          2. since switching to version 10, its only possible to create a new event by clicking at 12:00am in the calendar. I guess that has something to do with the workdays properties
          3. I've created a example with a Restdatasource here: http://com.moogle.at/calendar_timezone_bug_2/
          If I try to add an event by clicking on a day 12:00am, I can see in the developer Console that smartclient tries to create an event at 23:00.

          DSRequest:
          Code:
          {
              dataSource:"calendarDS", 
              operationType:"add", 
              componentId:"calendar", 
              data:{
                  startdate:"2015-02-02T23:00:00.000", 
                  enddate:"2015-02-02T23:00:00.000", 
                  name:"asdf", 
                  isc_metaDataPrefix:"_", 
                  isc_dataFormat:"json"
              }, 
              textMatchStyle:"exact", 
              willHandleError:true, 
              showPrompt:true, 
              requestId:"calendarDS$6272", 
              fallbackToEval:false, 
              lastClientEventThreadCode:"MUP7", 
              bypassCache:true, 
              isRestRequest:true, 
              dataFormat:"json"
          }
          Attached Files
          Last edited by alex430; 3 Feb 2015, 12:37. Reason: additional info

          Comment


            #6
            We'll take a look - for the future, please don't make major edits to existing posts, because we don't get automatic notifications about edits - post a reply if you have additional information or questions.

            It's also better if you just paste your standalone example code here, rather than directing us to running samples elsewhere.
            Last edited by Isomorphic; 4 Feb 2015, 23:54.

            Comment


              #7
              Hi Isomorphic!

              Thanks for the advice, I'll take care of this next time.

              Just for the sake of completeness, here is the sample code:

              Code:
              isc.RestDataSource.create({"ID":"calendarDS","operationBindings":[{"operationType":"fetch","dataProtocol":"postParams","dataURL":"http://com.moogle.at/calendarDS/index.php/data/fetch/calendar"},{"operationType":"add","dataProtocol":"postParams","dataURL":"http://com.moogle.at/calendarDS/index.php/data/add/calendar"},{"operationType":"remove","dataProtocol":"postParams","dataURL":"http://com.moogle.at/calendarDS/index.php/data/remove/calendar"},{"operationType":"update","dataProtocol":"postParams","dataURL":"http://com.moogle.at/calendarDS/index.php/data/update/calendar"}],"dataFormat":"json","canMultiSort":false,"noNullUpdates":true,"nullStringValue":"","fields":[{"name":"eventid","title":"eventid","primaryKey":true,"canEdit":false,"type":"integer"},{"name":"description","title":"description","type":"text","length":60},{"name":"name","title":"name","type":"text","length":20},{"name":"startdate","title":"startdate","type":"datetime"},{"name":"enddate","title":"enddate","type":"datetime"}],"model":"calendar","dataURLbase":"http://com.moogle.at/calendarDS/index.php/data"} );
              
              Time.adjustForDST = false;
              Time.setDefaultDisplayTimezone('+00:00');
              
              
              isc.Calendar.create({
                  ID: 'calendar',
                  startDateField: 'startdate',
                  endDateField: 'enddate',
                  nameField: 'name',
                  descriptionField: 'description',
                  //timeFormatter: 'toShortPadded24HourTime',
                  autoFetchData: true,
                  dataSource: calendarDS
              })

              Are there any new informations on this case?

              Comment


                #8
                We see this bug and it's under investigation - we'll update here when it's been fixed.

                Comment


                  #9
                  Hi!

                  Are there any news or updates available for this problem??
                  Having the same issues and havn't been able to fix them!

                  Comment


                    #10
                    We haven't got to this yet - we're aware of it, and it *is* queued to be looked at, but it's behind other reports from customers with support contracts, so there's no ETA.

                    Comment

                    Working...
                    X