simonpoole / OpeningHoursParser

Parser for string values according to the OSM opening hours specification
MIT License
32 stars 12 forks source link

Canonical form: Time span sunset-00:00 is not beautified #80

Open westnordost opened 9 months ago

westnordost commented 9 months ago

This library beautifies time ranges like

When the start time is an event time, this is however not done, which seems a little inconsistent. I.e. sunset-00:00 is not beautified to sunset-24:00

(I am looking deeply into details on parse results and differences between the parsers and their "canonical forms" of string creation results currently, so this is why I will probably post more issues over the next few days.)

simonpoole commented 9 months ago

Just to explain to the behaviour in the first two examples:

There are two different mechanisms at work which both only change the end time if there is actually a "numeric" start time value.

1) during parsing: if the end time < start time, the end time is corrected to the "extended time" format aka add 24 hours, except if we are in strict mode (then it is an error). 2) for output, depending on the flags "extended time" values that are larger than 24h will be output conventionally if they are unambiguous or in extended time format otherwise.

westnordost commented 9 months ago

except if we are in strict mode (then it is an error).

According to (current version of?) the specification, 16:00-04:00 is valid, though.

See https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#explain:extended_hour_minutes :

Can be used to express opening hours wrapping over midnight. Opening hours wrapping over midnight can also be expressed if the second time (e.g. 04:00) is less than the first time (e.g. 22:00) for a value like Fr,Sa 22:00-04:00 which is probably easier to read especially if the second time is greater (compare Fr,Sa 22:00-20:00 with Fr,Sa 22:00-44:00).

simonpoole commented 9 months ago

except if we are in strict mode (then it is an error). ^^^ time

According to (current version of?) the specification, 16:00-04:00 is valid, though.

It's the reason that the "strict time mode" flag exists as there was a lot of ambiguity around the whole subject and at a certain point I decided to relax the strict behaviour as you can spend the whole day arguing exactly what the original intent was.