Those two examples you posted are both using the "nightly build", but I think it is actually an old cached version. Using the 2.3.4 release I think it should work:
Regarding the time part not showing in the picker, the example was using ColumnControl 1.0.7. Using 1.1.0 (the current release) does have it showing. The updated links above use 1.1.0 and shows it working.
I just loaded up those two updated examples and yeah, they both show the date and time picker as I'd expect. I updated them both with current time data and they're both rendering as GMT instead of local time though.
Should be displaying as 16th Sept 2025 5:49pm regardless of what timezone you are in. I've just tried that on multiple browsers on two different computers (Linux and Windows 10) and that is what appears to be happening for me with different timezones set in the system settings.
There is no timezone information on the date there, and DataTables will just treat it as an absolute time. It doesn't attempt to translate it from UTC to localtime (which would be one possibility for ambiguous timezone dates).
Is that what is happening for you? Were you expecting that datetime stamp to be translated from Zulu time to local time?
The short answer is yes, I'm expecting it to recognize the date/time as UTC and then render it in local time.
In the current version of our the application, which uses a slightly older version of DataTables releases, that's what's happening. We're using timestamp data and we're forcing the type but that's a separate issue (which I'm guessing we'll need to resolve by updating to ISO-8601 dates - more on that in a moment). So for example, there's this data:
And this is what's displayed (note it's showing as UTC not local time):
As you pointed out, there's no timezone information (I may have initially assumed it was implied and didn't need t be specified - not sure if that's true) so I updated the annotation to include that (the 'Z' at the end):
Incidentally, replacing the '+0000' with 'Z' doesn't seem to make any difference so I'm guessing they're effectively equivalent.
So I'm confused about what I'm missing to get this to be recognized as UTC and then rendered as local time. What we're using currently does exactly that, though I understand that it's with timestamps and some of the behavior may be a bit of an accident as opposed to intended. Still, it's working and our users definitely need to see date/time data as local time or they'll get very confused. Any suggestions?
So I'm confused about what I'm missing to get this to be recognized as UTC and then rendered as local time.
DataTables doesn't currently do that I'm afraid. You would need a custom renderer, or to update the built in one to have timezone support. It is something I would like to do in future, but as of yet, it doesn't have that ability. Sorry.
Ah, ok. I assumed it would render it as local automatically (like is happening with the timestamp data). If I take either a timestamp (equivalent to 2025-09-17 13:18:00 in this case) or that UTC date and feed it to the JavaScript Date object it happens automatically:
I guess I figured something like that would be happening inside of the DataTables code, especially as the timestamp does render as local time in the table.
So now instead of the DataTables renderer:
render: DataTable.render.datetime()
I'm using this:
render: function (data) {
return data ? new Date(data).toLocaleString() : '';
},
That now renders the UTC date/time as a local date/time. Does this seem like the right approach?
There does seem to be an unexpected side effect to this which is the date/time picker is a different time. If I pick a date/time then the date/time that actually gets populated in the text box doesn't match. It looks like it's off by whatever my timezone offset is. Here you can see I've picked 11am but the text box gets populated with 5am.
Do I need to adjust the ColumnControl config or maybe the render config to keep them in sync?
One other thing we've been seeing is the date/time picker doesn't seem to consistently filter the table. Here you can see I picked a date after the date that's showing in the table but it's not getting filtered out. This, btw, is without the latest render adjustments (above) for the timezone and just uses DataTable.render.datetime():
This behavior seems to be tied to the time part of the picker not the date part. The date part works consistently from what I can tell. To be fair this is with the type: 'datetime' forced in the config so maybe it's something related to that. I know you don't recommend forcing the type but unfortunately it's still the case that if I remove the type then the filter defaults to "contains" instead of "equals" and if I change it to "equals" there's no date/time picker at all.
That now renders the UTC date/time as a local date/time. Does this seem like the right approach?
Yes, however, you'll hit other issues such as the one you then go on to mention. I'm afraid it boils down to the fact that I haven't yet implemented timezone support in DataTables, ColumnControl or any of the other extensions. That is something that I need to find some time to sit down and do. Sorry I don't have a better answer at the moment. At the moment DataTables will treat all date / time data that it rekognises as that with an ambigious timezone and thus display and work with it "unshifted" (I'm sure there is a proper term, but not sure what!).
Ok, that makes sense. It's interesting that the timestamp data has worked (i.e. renders as local time), if only by accident, up until recently. We've been using that for a while and not knowing any better just figured it was by design.
This morning I tried downgrading the DateTime extension by omitting it from the download builder and then downloading the 1.5.6 release and including that separately in the hope that it would get us the updates to keep the ColumnControl filter in sync with the table data without the change that's causing timestamps to now render as UTC instead of local time. Unfortunately that didn't work (it's still rendering as UTC). It was a long shot but I figured worth a try.
For the moment we're probably going to have to hold off on DataTables upgrades unless maybe we shut off any column date filtering so as to not confuse users, though that may an issue as well. I'll have to think through our options.
FWIW I've been referring to the difference between local and UTC as the offset so maybe "unshifted" is without the offset? Unoffset? That just sounds wrong.
Thanks for all your help sorting through this - much appreciated.
I came to the conclusion that it was going to be more painful to hang back and avoid releases than to try to patch the current release to work with the limitations I've got. I made a few changes to the DataTables code to get things working with the latest release.
Then I updated the searchDateTime var to use it where the SearchInput is created and to hide the date-related options. I also added a default "Show All" option.
var searchDateTime = {
defaults: {
clear: true,
format: '',
mask: '',
placeholder: '',
title: '',
titleAttr: ''
},
init: function (config) {
var _this = this;
var fromPicker = false;
var moment = DataTable.use('moment');
var luxon = DataTable.use('luxon');
var dt = this.dt();
var i18nBase = 'columnControl.search.datetime.';
var pickerFormat = '';
var dataSrcFormat = '';
var dateTime;
//var searchInput = new SearchInput(dt, this.idx())
var searchInput = new SearchInput(dt, this.idx(), false)
.type('date')
.addClass('dtcc-searchDateTime')
.sspTransform(function (val) { return toISO(val, pickerFormat, moment, luxon); })
.sspData({ mask: config.mask })
.clearable(config.clear)
.placeholder(config.placeholder)
.title(config.title)
.titleAttr(config.titleAttr)
.options([
{ label: 'Show All', value: 'tick' },
// { label: dt.i18n(i18nBase + 'equal', 'Equals'), value: 'equal' },
// { label: dt.i18n(i18nBase + 'notEqual', 'Does not equal'), value: 'notEqual' },
// { label: dt.i18n(i18nBase + 'greater', 'After'), value: 'greater' },
// { label: dt.i18n(i18nBase + 'less', 'Before'), value: 'less' },
{ label: dt.i18n(i18nBase + 'empty', 'Empty'), value: 'empty' },
{ label: dt.i18n(i18nBase + 'notEmpty', 'Not empty'), value: 'notEmpty' }
])
The result is all the ColumnControl options that you could use to select a date are hidden for now which is fine since as we discussed the pickers don't match the text inputs at the moment.
Two other two changes I made I'd suggest might be worth considering. First, I think it makes sense to have a "Show All" default. Without that it defaults to "Equals" since it's first in the list but it doesn't do anything until you type in the text field. It seems clearer having a "Show All" option as the default and an option you could set. The other thing I'd suggest is that for the "Empty" and "Not Empty" options I don't think it makes sense to show the secondary input. You wouldn't select "Empty" and then pick a date (something it's currently possible to do) - that doesn't make any sense and could definitely be confusing. Just my two cents.
I think I (hopefully) didn't miss anything getting this running. It seems to be working alright. And at least for now it means I can hopefully stay up to date with the latest and re-patch new releases as I go until there's additional DataTables timezone support.
Now date/times using timestamps render as local as we'd like.
Then I updated the SearchInput to take a param to show/hide the secondary ColumnControl input.
var SearchInput = /** @class */ (function () {
/**
* Create a container element, for consistent DOM structure and styling
*/
function SearchInput(dt, idx, showSecondaryInput = true) {
var _this = this;
this._type = 'text';
this._sspTransform = null;
this._sspData = {};
this._dt = dt;
this._idx = idx;
this._dom = {
clear: createElement('span', 'dtcc-search-clear', icons['x']),
container: createElement('div', SearchInput.classes.container),
typeIcon: createElement('div', 'dtcc-search-type-icon'),
searchIcon: createElement('div', 'dtcc-search-icon', icons['search']),
input: createElement('input', SearchInput.classes.input),
inputs: createElement('div'),
select: createElement('select', SearchInput.classes.select),
title: createElement('div', 'dtcc-search-title')
};
var dom = this._dom;
var originalIdx = idx;
dom.input.setAttribute('type', 'text');
dom.container.append(dom.title, dom.inputs);
if (showSecondaryInput) {
dom.inputs.append(dom.typeIcon, dom.select, dom.searchIcon, dom.clear, dom.input);
} else {
dom.inputs.append(dom.typeIcon, dom.select);
}
Then I updated the searchDateTime to use it where the SearchInput is created, I hid all the input options where you would pick a date and I added a default "Show All" option.
var searchDateTime = {
defaults: {
clear: true,
format: '',
mask: '',
placeholder: '',
title: '',
titleAttr: ''
},
init: function (config) {
var _this = this;
var fromPicker = false;
var moment = DataTable.use('moment');
var luxon = DataTable.use('luxon');
var dt = this.dt();
var i18nBase = 'columnControl.search.datetime.';
var pickerFormat = '';
var dataSrcFormat = '';
var dateTime;
//var searchInput = new SearchInput(dt, this.idx(), false)
var searchInput = new SearchInput(dt, this.idx(), false)
.type('date')
.addClass('dtcc-searchDateTime')
.sspTransform(function (val) { return toISO(val, pickerFormat, moment, luxon); })
.sspData({ mask: config.mask })
.clearable(config.clear)
.placeholder(config.placeholder)
.title(config.title)
.titleAttr(config.titleAttr)
.options([
{ label: 'Show All', value: 'tick' },
// { label: dt.i18n(i18nBase + 'equal', 'Equals'), value: 'equal' },
// { label: dt.i18n(i18nBase + 'notEqual', 'Does not equal'), value: 'notEqual' },
// { label: dt.i18n(i18nBase + 'greater', 'After'), value: 'greater' },
// { label: dt.i18n(i18nBase + 'less', 'Before'), value: 'less' },
{ label: dt.i18n(i18nBase + 'empty', 'Empty'), value: 'empty' },
{ label: dt.i18n(i18nBase + 'notEmpty', 'Not empty'), value: 'notEmpty' }
])
It seems to be working as I'd expect.
I think two of these changes are worth considering. I think it makes sense to have a "Show All" option as the default rather than having it default to "Equals" which doesn't do anything unless you type in the text field below it. It also gives users a clearer way to set it back to show everything rather than having to clear out an option's search text. The second thing is I think the secondary field should only show when appropriate. Currently you can pick "Empty" and then pick a date which won't work and could be confusing. Just my two cents.
So for now I have a patch I can hopefully reapply to new releases until there's additional timezone support in DataTables.
The "Show All" option is an interesting idea and I'll certainly consider it. It does mean that an extra action is required by the end user when performing a filtering is the downside I see - rather than being able to just start typing or selecting a date, they need to perform a selection option. But then it might be worth the trade off. I'll definitely keep it in mind!
Many thanks for showing me the UTC patch and good to hear you've got a short term workaround. Proper timezone support is on my todo list .
Answers
Hi Ben,
Those two examples you posted are both using the "nightly build", but I think it is actually an old cached version. Using the 2.3.4 release I think it should work:
Regarding the time part not showing in the picker, the example was using ColumnControl 1.0.7. Using 1.1.0 (the current release) does have it showing. The updated links above use 1.1.0 and shows it working.
Regards,
Allan
Allan,
I just loaded up those two updated examples and yeah, they both show the date and time picker as I'd expect. I updated them both with current time data and they're both rendering as GMT instead of local time though.
https://live.datatables.net/hudehaqi/1/edit
https://live.datatables.net/likevasi/1/edit
Shouldn't they be rendering as local time or am I missing something?
Thanks.
Ben
Hi Ben,
Should be displaying as 16th Sept 2025 5:49pm regardless of what timezone you are in. I've just tried that on multiple browsers on two different computers (Linux and Windows 10) and that is what appears to be happening for me with different timezones set in the system settings.
There is no timezone information on the date there, and DataTables will just treat it as an absolute time. It doesn't attempt to translate it from UTC to localtime (which would be one possibility for ambiguous timezone dates).
Is that what is happening for you? Were you expecting that datetime stamp to be translated from Zulu time to local time?
Allan
Allan,
The short answer is yes, I'm expecting it to recognize the date/time as UTC and then render it in local time.
In the current version of our the application, which uses a slightly older version of DataTables releases, that's what's happening. We're using timestamp data and we're forcing the type but that's a separate issue (which I'm guessing we'll need to resolve by updating to ISO-8601 dates - more on that in a moment). So for example, there's this data:
startTimeOfAlert: 1758115080380
which is this date/time:
2025-09-17 13:18:00
using this config:
and it's being rendered as local time:
Btw, I'm using this site to for example dates and converting dates:
https://timestamp.onl/
So as you can see it definitely recognizes it as UTC (or assumes it is I suppose) and reformats it as local time as we'd expect.
I then loaded in the code I've got stashed to convert our dates over to ISO-8601. Now I've got this data:
startTimeOfAlert: "2025-09-17T13:39:43"
using this config (note, I've removed the forced date type):
And this is what's displayed (note it's showing as UTC not local time):
As you pointed out, there's no timezone information (I may have initially assumed it was implied and didn't need t be specified - not sure if that's true) so I updated the annotation to include that (the 'Z' at the end):
Now, it's generating the date/time like this (clearly UTC):
2025-09-17T13:58:06+0000
However, it's still being rendered as UTC in the app, not as local time:
I also updated the example to the same format:
https://live.datatables.net/johuciwi/1/edit
and that's showing as UTC not local time.
Incidentally, replacing the '+0000' with 'Z' doesn't seem to make any difference so I'm guessing they're effectively equivalent.
So I'm confused about what I'm missing to get this to be recognized as UTC and then rendered as local time. What we're using currently does exactly that, though I understand that it's with timestamps and some of the behavior may be a bit of an accident as opposed to intended. Still, it's working and our users definitely need to see date/time data as local time or they'll get very confused. Any suggestions?
Thanks.
Ben
DataTables doesn't currently do that I'm afraid. You would need a custom renderer, or to update the built in one to have timezone support. It is something I would like to do in future, but as of yet, it doesn't have that ability. Sorry.
Allan
Allan,
Ah, ok. I assumed it would render it as local automatically (like is happening with the timestamp data). If I take either a timestamp (equivalent to 2025-09-17 13:18:00 in this case) or that UTC date and feed it to the JavaScript Date object it happens automatically:
I guess I figured something like that would be happening inside of the DataTables code, especially as the timestamp does render as local time in the table.
So now instead of the DataTables renderer:
I'm using this:
That now renders the UTC date/time as a local date/time. Does this seem like the right approach?
There does seem to be an unexpected side effect to this which is the date/time picker is a different time. If I pick a date/time then the date/time that actually gets populated in the text box doesn't match. It looks like it's off by whatever my timezone offset is. Here you can see I've picked 11am but the text box gets populated with 5am.
Do I need to adjust the ColumnControl config or maybe the render config to keep them in sync?
One other thing we've been seeing is the date/time picker doesn't seem to consistently filter the table. Here you can see I picked a date after the date that's showing in the table but it's not getting filtered out. This, btw, is without the latest render adjustments (above) for the timezone and just uses DataTable.render.datetime():
This behavior seems to be tied to the time part of the picker not the date part. The date part works consistently from what I can tell. To be fair this is with the type: 'datetime' forced in the config so maybe it's something related to that. I know you don't recommend forcing the type but unfortunately it's still the case that if I remove the type then the filter defaults to "contains" instead of "equals" and if I change it to "equals" there's no date/time picker at all.
Thanks.
Ben
Hi Ben,
Yes, however, you'll hit other issues such as the one you then go on to mention. I'm afraid it boils down to the fact that I haven't yet implemented timezone support in DataTables, ColumnControl or any of the other extensions. That is something that I need to find some time to sit down and do. Sorry I don't have a better answer at the moment. At the moment DataTables will treat all date / time data that it rekognises as that with an ambigious timezone and thus display and work with it "unshifted" (I'm sure there is a proper term, but not sure what!).
Allan
Allan,
Ok, that makes sense. It's interesting that the timestamp data has worked (i.e. renders as local time), if only by accident, up until recently. We've been using that for a while and not knowing any better just figured it was by design.
This morning I tried downgrading the DateTime extension by omitting it from the download builder and then downloading the 1.5.6 release and including that separately in the hope that it would get us the updates to keep the ColumnControl filter in sync with the table data without the change that's causing timestamps to now render as UTC instead of local time. Unfortunately that didn't work (it's still rendering as UTC). It was a long shot but I figured worth a try.
For the moment we're probably going to have to hold off on DataTables upgrades unless maybe we shut off any column date filtering so as to not confuse users, though that may an issue as well. I'll have to think through our options.
FWIW I've been referring to the difference between local and UTC as the offset so maybe "unshifted" is without the offset? Unoffset? That just sounds wrong.
Thanks for all your help sorting through this - much appreciated.
Ben
Allan,
I came to the conclusion that it was going to be more painful to hang back and avoid releases than to try to patch the current release to work with the limitations I've got. I made a few changes to the DataTables code to get things working with the latest release.
I rolled back this change:
https://github.com/DataTables/DataTablesSrc/compare/26e9e613281a415643907841d0d7d1b3ac6a99fb...82910e1d58f4693abafab402eda74e131dbb7fd3
so it now looks like this:
Dates/times using timestamps now go back to rendering as local as we'd like.
I updated the SearchInput to take a param to show/hide the secondary input for ColumnControl - used at the bottom of this snippet:
Then I updated the searchDateTime var to use it where the SearchInput is created and to hide the date-related options. I also added a default "Show All" option.
The result is all the ColumnControl options that you could use to select a date are hidden for now which is fine since as we discussed the pickers don't match the text inputs at the moment.
Two other two changes I made I'd suggest might be worth considering. First, I think it makes sense to have a "Show All" default. Without that it defaults to "Equals" since it's first in the list but it doesn't do anything until you type in the text field. It seems clearer having a "Show All" option as the default and an option you could set. The other thing I'd suggest is that for the "Empty" and "Not Empty" options I don't think it makes sense to show the secondary input. You wouldn't select "Empty" and then pick a date (something it's currently possible to do) - that doesn't make any sense and could definitely be confusing. Just my two cents.
I think I (hopefully) didn't miss anything getting this running. It seems to be working alright. And at least for now it means I can hopefully stay up to date with the latest and re-patch new releases as I go until there's additional DataTables timezone support.
Thanks.
Ben
Allan,
I decided it was going to be more painful to hang back and avoid new releases than to patch the code to make it work with the limitations I've got.
I rolled back this change:
https://github.com/DataTables/DataTablesSrc/compare/26e9e613281a415643907841d0d7d1b3ac6a99fb...82910e1d58f4693abafab402eda74e131dbb7fd3
So it looks like this:
Now date/times using timestamps render as local as we'd like.
Then I updated the SearchInput to take a param to show/hide the secondary ColumnControl input.
Then I updated the searchDateTime to use it where the SearchInput is created, I hid all the input options where you would pick a date and I added a default "Show All" option.
It seems to be working as I'd expect.
I think two of these changes are worth considering. I think it makes sense to have a "Show All" option as the default rather than having it default to "Equals" which doesn't do anything unless you type in the text field below it. It also gives users a clearer way to set it back to show everything rather than having to clear out an option's search text. The second thing is I think the secondary field should only show when appropriate. Currently you can pick "Empty" and then pick a date which won't work and could be confusing. Just my two cents.
So for now I have a patch I can hopefully reapply to new releases until there's additional timezone support in DataTables.
Thanks.
Ben
Hi Ben,
The "Show All" option is an interesting idea and I'll certainly consider it. It does mean that an extra action is required by the end user when performing a filtering is the downside I see - rather than being able to just start typing or selecting a date, they need to perform a selection option. But then it might be worth the trade off. I'll definitely keep it in mind!
Many thanks for showing me the UTC patch and good to hear you've got a short term workaround. Proper timezone support is on my todo list
.
Allan