Time rendering behavior changed to UTC+0

Time rendering behavior changed to UTC+0

elstupidelstupid Posts: 23Questions: 4Answers: 1

A short while ago I bumped my Datatables version from 2.3.2 to 2.3.7
Now I notice the built-in datetime render function Datatables.render.datetime() (and time()) converts my times to UTC+0, which confused a lot of my users (including me).

For example, my SQL Server returns a date as '2026-04-18T14:14:32.343' . With the time() function this is displayed now as '14:14:32'

For now I downgraded again, but is this somewhere documented? I'm having trouble to find it.
I could find an open Github issues which involves timezones, https://github.com/DataTables/DataTablesSrc/issues/289

How to use the render function now to leave my time untouched?

Answers

  • allanallan Posts: 65,686Questions: 1Answers: 10,924 Site admin

    2026-04-18T14:14:32.343

    This has no timezone information and should be displayed as 14:14:32. If it has a timezone or even a Z then it could possibly convert to another time zone (eg local time, per the browser), but DataTables does not currently support timezones. That is something that will be coming during the summer.

    If that date/time stamp was displayed as 14:14:32 what would you expect it to be displayed as?

    I suspect you are encountering a bug fix here (and somewhat ironically you we using the buggy behaviour!).

    Allan

  • elstupidelstupid Posts: 23Questions: 4Answers: 1
    edited April 19

    Thanks Allan. The date I gave as an example showed before just as 14:14:32 and now (in The Netherlands where users are they live at UTC+1 plus an extra for daylight saving time), it shows up as 12:14:32

    I'm now working at Sri Lanka, which is even more "off". To show you an example while debugging from the browser. You can see the data part says 15:18:00 and after rendering it says 09:48:00.

    If it is a bugfix, that's fine for sure, but how to solve this? My SQL Server cannot add the timezone because it has no idea of that. It just saves a datetime to a table.

  • allanallan Posts: 65,686Questions: 1Answers: 10,924 Site admin

    In your original post you said 2026-04-18T14:14:32.343 shows as 14:14:32, but in your second post you say that it is 12:14:32 or different depending on the time zone. If that later is happening that is certainly wrong and needs to be corrected. The former is what I would expect.

    Can you give me a link to a test case showing the issue so I can investigate please?

    Allan

  • elstupidelstupid Posts: 23Questions: 4Answers: 1

    Sorry for the confusion, you're absolutely right. My first post is wrong about the display, I mixed it up. However I can't edit it anymore.

    To my suprrise it doens't happen with a test case:
    https://live.datatables.net/figuniye/1/edit

    You can see from my debug screenshot the input data says "2026-04-19T15:18:00" and after rendering the time remaining is "09:48:00".

    So could it be the jslive is on a server with no timezone offset and Moment is interacting with my local webserver?
    My production webserver is a Windows machine with UTC+2
    My local webserver is a Win11 machine with UTC+5:30

  • allanallan Posts: 65,686Questions: 1Answers: 10,924 Site admin

    So could it be the jslive is on a server with no timezone offset and Moment is interacting with my local webserver?

    The web server will have no impact on this. It is entirely a client-side operation. Also, your example isn't loading Moment, so that isn't at play here.

    I'm GMT+1 at the moment, and I am actually seeing the issue you mention when I update your example to use the renderer.

    Interestingly, if I make the time stamps Zulu time, then it works as expected. I'll dig into this today and post back when I have a better understanding of what is happening and why.

    Allan

  • elstupidelstupid Posts: 23Questions: 4Answers: 1

    Thanks Allan. I should take a better look next time, now I see then renderer wasn't even used in my example.

  • allanallan Posts: 65,686Questions: 1Answers: 10,924 Site admin

    I've committed a change which I believe addresses this issue. The example works now when using the nightly build.

    Could you try the nightly in your local app for me, and if you can confirm that the issue is resolved I'll get a 2.3.8 release out.

    Regards,
    Allan

  • elstupidelstupid Posts: 23Questions: 4Answers: 1
    edited April 20

    I would like to, but I'm using the CDN like this

    <script src="https://cdn.datatables.net/v/dt/jszip-3.10.1/dt-2.3.7/b-3.2.6/b-html5-3.2.6/b-print-3.2.6/date-1.6.3/fh-4.0.6/kt-2.12.2/r-3.0.8/rg-1.6.0/datatables.min.js" integrity="sha384-TiXnLzot6g1TVd2f/o7tscqKhMrbahHF453b0a66RvdBzJy9/ngJrV3Zn6WxAdf2" crossorigin="anonymous"></script>

    How to continue?

    Edit: in your example (I guess this one, you didn't link it) it works for me, I see times now displayed at thy should B)

  • allanallan Posts: 65,686Questions: 1Answers: 10,924 Site admin
    <script src="https://nightly.datatables.net/js/dataTables.js?2026-04-20"></script>
    <script src="https://cdn.datatables.net/v/dt/jszip-3.10.1/b-3.2.6/b-html5-3.2.6/b-print-3.2.6/date-1.6.3/fh-4.0.6/kt-2.12.2/r-3.0.8/rg-1.6.0/datatables.min.js"></script>
    

    Example: https://live.datatables.net/figuniye/5/edit .

    One thing worth noting is that adding Z as I did before will actually cause it to shift now, as the input and output are both localtime now.

    Proper support for timezones will come in future...

    Allan

  • elstupidelstupid Posts: 23Questions: 4Answers: 1

    Using the nightly it works correctly on my end also.
    I'm not using z actually, so for me it is ok.

    Thanks for the outstanding support!

  • allanallan Posts: 65,686Questions: 1Answers: 10,924 Site admin

    I had an idea last night for improving this situation a little and have committed it here. It will now retain the timezone (if there is one) from the reading of the data through to the output. If there is no timezone it is treated as locale time (per ISO8601) and again the input and output use the same. So now with, or without a Z (or other timezone identifier) it should work correctly :).

    I'll do a 2.3.8 release with this change (and others that are in the release queue) this week (hopefully tomorrow).

    Allan

Sign In or Register to comment.