Is there any update on this? It would be awesome if the Date/Time Input components would operate in terms of moment instead of Date objects so that we could take advantage of timezone support in moment-timezone. Working in terms of moment would also make i18n easier, thanks to moment's locale support, and locale-based format patterns.
@UselessPickles we're actually in the process of considering dropping the moment dependency entirely: see #1952 (and issue #317). there's also issue #1852, proposing using ISO _strings_ rather than Date objects, because ISO strings _do_ include precise timezone information.
I think https://github.com/palantir/blueprint/issues/1852 might be a better approach so that we're not tied to moment? If you agree I'll close this issue in favor of that one.
If working in terms of ISO strings, then I suppose it would be simple enough to create a wrapper component that works in terms of moment and a timezone ID if I want to use moment in my code.
+1 to moving forward with some kind of resolution here. I'm currently evaluating Blueprint v2 and was disheartened to find out today that the various date and time pickers don't support timezones. I'm building an app that supports switching back and forth between UTC and the user's local timezone, so our date/time picker needs to support that as well.
@kaiyoma what kind of support would get you over the line? Where does Blueprint fall short? Can you support timezones through a wrapper component?
Being able to pass in an ISO string or Moment object would be the most flexible/complete solution, as you'd be able to show the correct date/time in any arbitrary timezone. That could be useful to some others, whereas my needs are simply to flip back and forth between the local timezone and UTC.
Right now, we're using react-datetime in our project:
https://github.com/YouCanBookMe/react-datetime
You can see that their API supports a utc prop. If you guys had a similar prop, that would satisfy my needs. Given that there are already date/time pickers out there that support UTC vs. local time, I see no reason to write custom code to do the timezone shift manually. (That kind of code is prone to bugs or logic errors anyway.) Given the choice, I'm going to stick with react-datetime because it already does what I need.
Most helpful comment
Being able to pass in an ISO string or Moment object would be the most flexible/complete solution, as you'd be able to show the correct date/time in any arbitrary timezone. That could be useful to some others, whereas my needs are simply to flip back and forth between the local timezone and UTC.
Right now, we're using
react-datetimein our project:https://github.com/YouCanBookMe/react-datetime
You can see that their API supports a
utcprop. If you guys had a similar prop, that would satisfy my needs. Given that there are already date/time pickers out there that support UTC vs. local time, I see no reason to write custom code to do the timezone shift manually. (That kind of code is prone to bugs or logic errors anyway.) Given the choice, I'm going to stick withreact-datetimebecause it already does what I need.