The Calendar date picker component uses data attributes like the following to store the date value of each date in the picker:
data-coreui-date="Wed Dec 03 2025 00:00:00 GMT+0100 (Central European Standard Time)". See screenshot.

Note that that date is December 3, but is only December 3 in Central European time or other timezone with GMT+1 or greater offset. in UTC or less it is December 2.

This timestamp is apparently rendered in user-local (using browser timezone offset). Probably some code somewhere doing date.setHours(0,0,0,0) to zero out the time component of the date (rather than date.setUTCHours(0,0,0,0).

The problem is, I might have users in many different timezones and as far as I can tell the date picker is timezone agnostic except for this bit.

Now if I try to write a filter (disabledDates = function ...) to for instance blacklist a list of dates... I can't do a direct comparison because the parameters from coreui datepicker to my filter function are these user-local dates whereas I am using UTC dates.

Is the date the date picker gives my filter function Dec 2 or Dec 3? I can't tell without assuming how date picker is working (e.g. assume they are using getTimezoneOffset()... or I have to avoid using UTC anywhere and instead assume date picker will always use these zeroed out local dates.

I can work around this by using my date blacklist (e.g. YYYY-MM-DD and constructing dates from these and then using setHours(0,0,0,0) to zero out the time component (potentially changing the UTC date). But when it comes time to pass the date to the server which may want to treat the date as a fixed timezone, we need to convert back to a string and parse to strip out the user timezone component (shifting the timezone of the date) so that the date is not interpreted by the server as yesterday or tomorrow when converted to target timezone.

This feels like needless complexity. Unless the datepicker is going to support the ability for me to say: "use absolute timezone America/Denver or use browser (user-local) timezone" it seems like it would keep things much simpler if datepicker stuck with UTC everywhere so it isn't so complicated to write filters.

The biggest problem here is that the behaviour is not well documented and doesn't do what you would expect (passing timezone-specific dates to filter function even though there is no ability to configure timezone or offset in the component).

Of course changing this might break existing users (including me since I've written code to adapt to how filters work based on empirical testing of how the date picker works), so would probably require adding some additional config like forceUTC.

Adding to the confusion, the date object passed by date picker when date is selected (event 'dateChange.coreui.date-picker') is UTC midnight rather than user local. 🤦

Wed Dec 03 2025 01:00:00 GMT+0100 (Central European Standard Time)

So my filter code needs to work with user-local date objects (setHours(0,0,0,0)) and my non-filter code (e.g. date selected) should work with UTC date objects.

Am I missing something?