React-dates: Is there a way of forcing the timezone to be different than the local timezone?

[linorabolini]

[majapw]

@linorabolini Can you describe the usecase? Or the problem that you're seeing? I ... don't currently think it's possible unfortunately.

I'm def worried it could lead to weird behavior, but maybe we could somehow override the way days are generated.

[linorabolini]

Hi @majapw yeah I was afraid of that ! haha

we are making an app that would let users do date management. The thing is that the values returned by the Day Picker component depend on the timezone the user is in. So a same day pick for me (France) would have a different value for someone in the US, because the day picker returns the startOf('day') of the selected day, in local time.

I made a work around and it works for us, but I was wondering if there was another less 'hacky' way.

The workaround involves just calculating and adding the offset to the date selected. So no matter the timezone, the unix value would be absolute.

I believe it could be a great upgrade to the calendar, would you keep me posted if you guys add it ?

[sontek]

My use case for this is an event management app. The event has a location that is almost always different than where the meeting planner is, so we need the datepicker to be the timezone of the event and not the local timezone of the planner.

[HartiganHM]

UPDATE 8.24.18

Looks like the issue here was inside of isDayBlocked and isOutsideRange. Any sort of timezone conversion there was causing the calendar to render incorrectly.

For anyone looking for a possible solution to force timezone functionality, what I used was to have a string reference for today saved in local state based on the required timezone (which is passed through as a timezone prop to the parent component) which I can then use as a reference point for determining if certain dates are blocked or in the past. It looks something like this:

class Wrapper extends Component {
  state = {
    today = today: this.props.timezone
      ? moment()
        .tz(this.props.timezone)
        .format('YYYY-MM-DD')
      : moment().format('YYYY-MM-DD')
  }

  render() {
    return <DayPickerSingleDateController ... />
  }
}

Trying to convert based on timezone in any of the DayPickerSingleDateController methods caused all sorts of errors, so I'm handling any necessary timezone conversion elsewhere. Hope this helps!

ORIGINAL POST 8.23.18

@majapw I'll chime in and say that we have a use case for timezone support as well. We'll be using the DatePickerSingleDateController and DayPickerRangeController for different stores that have a set location in a specific timezone. If someone is looking at a store in Denver from NY, we want the dates to match the timezone in Denver.

Right now it works up until NY crosses into the next day, which is where we start to see some weird behavior. The dates themselves initially render correctly, but once we select a day, all of the days are mismatched to the day prior. In the first screenshot below, we set today's date to be selected by default on initial render. Once we click the next day, the clicked day changes to the day prior. On clicking and moving the mouse away from the initially selected date, it changes as well.

I've run through a few workarounds in an attempt to force the correct date, but the date clicked changes to the previous date each time (eg if I click the 23rd, it will change to the 22nd). It's worth noting that this isn't just a visual problem either. The date returned from onDateChange will format to the prior date instead of the date selected. Additionally, these screenshots were taken while my machine was set to a timezone in Japan. Happy to provide further details and any help is appreciated!

[mmiszy]

My use case for this feature: We're an international team but our "reference timezone" is always UTC. So we want our datepickers to always work in UTC and always show the same date, no matter if I'm in Europe, Asia or Americas.
Currently I'm using a trick I'm not very proud of: date.format('YYYY-MM-DDT00:00:00.000Z')

[joetidee]

Yeah, would be good to supply a prop to this date picker, e.g. timezone="America/New_York", so that the date it returns is in the specified timezone. This allows date pickers to have their timezones set ad-hoc, rather than rely on globally setting moment.tz("America/New_York") across an entire application.

[neaumusic]

Yea picking a date is not the same as picking a timestamp, and if we're storing the date in an ISO string, it's UTC+0, but a UTC-based moment object is still being shown as a local date

export const localDate = dateTime =>
  moment(moment(dateTime).format('YYYY-MM-DD'));

export const utcDate = dateTime =>
  moment.utc(moment.utc(dateTime).format('YYYY-MM-DD'));

export const localUtcDate = dateTime =>
  moment(moment.utc(dateTime).format('YYYY-MM-DD'));

export const utcLocalDate = dateTime =>
  moment.utc(moment(dateTime).format('YYYY-MM-DD'));

[AshwinTayson]

@majapw Any update on this? We have the same use case as mentioned above by @mmiszy

[SimonChris]

I would also very much like this to be implemented. I exclusively use UTC time, and feeding utc moments to the datepicker causes issues with the day being off by one.

The other datepicker I use (react-datetime) have a simple 'utc' prop that fixes all of this.