TimeZones and GMT, BST (GMT+1) problem

4 posts, 0 answers
  1. Glyn
    Glyn avatar
    9 posts
    Member since:
    Jul 2013

    Posted 21 Aug 2014 Link to this post

    Hi all,  I am having a problem with the Scheduler and the UK summertime timezone.

    on Create / Update:
    If I create an event/booking on the scheduler (in August for eg.) by clicking on a 09:00 time slot, the json start time is sent as 08:00
    (I am assuming this is the Scheduler trying to be clever and storing the time as GMT rather than current system time (BST) )

    on Read:
    When this event is read back into the scheduler from the database, which is stored as 08:00, it displays it as is in the 08:00 slot
    (not reversing the BST offset used when it saved)

    If I do this same procedure for a date in November (no longer in BST) the time slot is both saved and retrieved at the correct time. 

    If have tried this, by setting the scheduler timezone to "Europe/London", also tried the scheme timezone to "Europe/London"
    Also tried ignoring the timezones completely.
    In every scenario it seems it still has this inconsistency of reading and displaying in what-ever is stored, but then saving in GMT whatever the current offset.  

    Help?  Is there a setting I am missing?
    Has anyone else in the UK got round this without writing your own hour fiddle if it's BST/GMT, on the create/update ajax.

    With thanks

    Glyn

  2. Vladimir Iliev
    Admin
    Vladimir Iliev avatar
    2194 posts

    Posted 22 Aug 2014 Link to this post

    Hi Glyn,

    Could you please check the following points below and confirm that they are implemented in your project:
    1. The Scheduler "timezone" option is set
    2. The "kendo.timezones.min.js" script is included to the project
    3. All Kendo UI scripts are the same version which is v2014.2.716
    4. The dates are correctly serialized before sending to the server using the "kendo.stringify" method, which formats the date in ISO format.
    5. The server correctly creates UTC date from the received date without additionally offsetting it.For example if you are using MVC as backend you can check this help article which describes how to achieve this.

    Also if the above points are already implemented and you still experience the described behavior - please provide runable example where the issue is reproduced. This would help us pinpoint the exact reason for this behavior.


    Regards,
    Vladimir Iliev
    Telerik
     
    Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
     
  3. Glyn
    Glyn avatar
    9 posts
    Member since:
    Jul 2013

    Posted 22 Aug 2014 Link to this post

    Hi Vladimir,
    Thanks for the reply.

    I've tried checking adding the timezone, including the timezones script and kendo.stringify is being used.

    I am handling the backend storage myself and I do not know or use MVC, but the help article you supplied seems to be implying that you have to set the database to also work with UTC.

    I am assuming then, that this behaviour of always creating json with UTC dates, but reading json dates "as is" is norm for the scheduler widget.
    If this is the case, I will have to write my own UTC to local timezone function on my backend.

    With thanks
    Glyn
  4. Vladimir Iliev
    Admin
    Vladimir Iliev avatar
    2194 posts

    Posted 22 Aug 2014 Link to this post

    Hi Glyn,


    Basically the scheduler dataSource always sends and expects to receive UTC dates from the server - that why you should make sure the following points are true:
    • The server understands that the received dates are UTC (create / update)
    • The sever sends back to the scheduler only UTC dates (read)

    The best possible approach would be to save the dates into the DataBase as UTC without additionally offsetting them on each read / write operation.


    Regards,
    Vladimir Iliev
    Telerik
     
    Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
     
Back to Top