Handling internationalization with UTC Offset

[FR073N]

One thing that's missing from this specification to make it really complete, is UTC offset.

Let me give you an example. We're leaving in France. The opening hour of my establishment are Mo 10:00-18:00.

When developping a full scale app, and displaying this opening hours for a user in London we'll see Monday 10:00 - 18:00, but we won't know at all what it represents.

If the format had something like the UTC Offset handlel inside, example Mo 10:00-18:00|+120, we would know that, when it's 9:00 at London, it's actually open.

With this one data, we'll be able to handle international simple opening hours.

[ypid]

I don’t see UTC offset in the opening hours value itself as a good solution to your use case.

Contra:

• It would clutter all values.
• All values in OSM would need to be updated (mass edit?).
• (I don’t like the proposed format. There are existing standards that we should respect: RFC 3339.)

Pro:

• Makes evaluation easier.

The offset is not needed. To evaluate opening hours, we should consider the reverse geocoding information of the POI and then use it to derive the UTC offset and convert the timestamp into the local timestamp of the user. You have a valid point here because this library already gets reverse geocoding information passed for other things like sunset and public holiday and so on so this is a good idea and the library is the right place to handle this. I think this also solves other open issues (duplicates?) about wrong timezones. Still, I would say the communication has always been that opening hours are in local time which makes this not count as a bug.

What do you think?

[FR073N]

Feature tag would be a better tag you're right.

You've first two points in the cons section are valid. This may need some mass migration, and will add a lot of data. So it's these arguments against the easier evalution argument.

About the existing standards, I really like the format you provided but because we already use the - as separator and + as the open end sign, wouldn't this cause some confusion ?

*Example : *

Mo-Fr 10:00-18:00, Sa 10:00-14:00+02:00  //+2:00 meaning we're in Paris 
Mo-Fr 10:00-18:00, Sa 10:00-14:00-03:00  //-3:00 Sao Polo
Mo 22:00++02:00
Mo 22:00+-03:00 

I'm sure we can find a solution with this standard.

I'm not sure to understand you're last paragraph : I never used the sunset format for example, nor get into the full analyze of the public holiday. How are we getting the reverse geocoding information ?

[ypid]

How are we getting the reverse geocoding information ?

All documented here: https://github.com/opening-hours/opening_hours.js#library-api

To restate, I don’t see a good reason to add this info to OSM or the spec. It is redundant. Opening hours are attached to POIs as attribute and the POI has a geo location from which the timezone can be derived.