Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
westnordost opened this issue Jan 8, 2024 · 3 comments
Open

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

westnordost opened this issue Jan 8, 2024 · 3 comments

Comments

@westnordost
Copy link
Contributor

This library beautifies time ranges like

  • 16:00-0:00 => 16:00-24:00
  • 16:00-28:00 => 16:00-04:00

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
Copy link
Owner

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
Copy link
Contributor Author

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
Copy link
Owner

simonpoole commented Jan 8, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants