Output time zone taken into account in all methods? about opening-hours HOT 2 CLOSED

Hello,

Indeed when dumping the time string data, no transformation to DateTime object is done at any moment and timezones are not read for this part of the process.

While it just looks like simple shifting when taking '09:00-12:00' from UTC to Prague, it's a completely different story when taking times close to 0 or 23:59, having a 00::-24:00 which means the range continue over the next day, and then you now involves timezone in and out ranging from -12 to +14 so an range on Sunday can become a range starting on Monday and finishing on Tuesday. Then come the exceptions/holidays added on top.

So while I agree it would make sense and I would be happy to help anyone wanting to propose a pull-request for this, I'd prefer to give a warning that it might be a more painful task than expected.

I need to create a date-time object from them and set the timezone manually which is quite inconvenient.

Be careful with this approach as it has the same pitfall, it works only when you're sure the time range still happen in the same day, i.e. that the time between midnight and first opening and time between last closing and midnight are both bigger than the offset difference between input and output timezone.

from opening-hours.

Hi, thank you for the quick response!

Thanks for pointing out the problem with the overlapping days because of the times close to 0 or 23:59. I am aware of it and I have been struggling with it for a while 😄

After a discussion with my colleague today, I realized the opening hours timezones should not be an issue on our project at all - basically, the opening hours are always tight to a particular store that has a location and the opening hours should be always presented in the timezone of the store location, no matter from where you want to display them.

TLDR, for now, it makes sense to keep the opening hours static and not change them with time zones.

I am closing this issue for now, thank you.

from opening-hours.