Talk:Proposed features/Time domains

From OpenStreetMap Wiki
Jump to: navigation, search

Time Zones

You should make Time Zone mandatory, at least in some cases, at least supported.
Example: people board on a ship and go to the restaurant: too many people, we'll come back for the 2nd service; it was the second service: they did not know that the ship's TZ was that of the destination.
The sun never sets on our empire (Charles Quint, Alexander III le Grand).

You are not supposed to map ships. -- Eckhart 16:47, 20 January 2013 (UTC)
You can surely map the permanently moored historical ones. Do they have restaurants? (talk) 12:07, 21 August 2015 (UTC)

I think time zones are useful, but not for the reasons the commenter above described. Time zones are for easing life for programmer which wouldn't be required to calculate a timezone for the given location. Also, there are edge cases, towns or even buildings in two different timezones. --Vanuan (talk) 14:27, 17 September 2014 (UTC)

I'd go with time zone is NOT mandatory. I think time zones should default to the local time zone of the area being mapped. We try to make OSM simple to use, so adding complexity for the data capturer is not good. Put the complexity where it belongs - in the server software. A programmer would not be scared of developing a library of code to work out a local time zone for any given site. Write it once, use it forever.

You will very seldom need to compare opening hours in different time zones in a mapping context. Most users will want to know opening times for local purposes, so local time will do. Only in edge cases - as mentioned - would it be necessary to be explicit about the zone. So we do need a way to enter that UTM+ or UTM- value. (talk) 12:07, 21 August 2015 (UTC)

Wrapping time intervals


The proposal says: "For time intervals, if the start time is later than the end time, the time interval wraps onto the same day." I disagree with this. As discussed in Talk:Key:opening_hours#Closing_time_on_the_next_day, this kind of time interval is proposed to indicate that the end time is for the next day. That's certainly how I see such opening times are indicated in the actual signage of establishments.

For example, here's how the opening hours of the Starbucks near my office is written on the website[1] and displayed on the actual signage in the store:

  • M - Th - 7:00am - 1:30am
  • F - Sat - 7:00am - 3:30am
  • Sun - 8:30am - 1:30am

I expect to encode this fairly straightforward like this:

Mo-Th 07:00-01:30; Fr-Sa 07:00-03:30; Su 08:30-01:30

--seav 19:10, 4 November 2012 (UTC)

There are two problems with this approach:
  1. First of all, as the opening_hour talk says, it is not entirely clear where the wrapping should take place: We 23:45-16:00 could be easily interpreted as Tu 23:45-24:00; We 00:00-16:00 since most parts of the time interval are on Wednesday.
  2. More important, there is also a problem with the precedence rule: take Mo-Th 07:00-01:30; Fr-Sa 07:00-03:30; Su 08:30-01:30 as example, and assume current time being Sunday 1:00am. The day of the right-most rule matches (Sunday), therefore the right-most rule is the one we care about. The time does not match, and we therefore conclude the shop is closed! -- Eckhart 19:22, 4 November 2012 (UTC)
(Your example for the second point does not count since the store is open at 1:00am at any day of the week, but I get your point as if you had used a better example.) Anyway. As a general unwritten guideline, we make mapping (and tagging) for the user easier. It's much easier for a computer to compute the necessary opening times including wrapped times than it is for the user to readjust the tagging of the information to fit your scheme.
As for your first problem, this is not a problem. We are talking about opening times and the day corresponds to the day when the establishment opens regardless of whether the establishment has more open times on the next day. As an example, a dance club in my area opens at 10pm on Saturdays and usually closes on 6:00 to 7:00am the next day (usually sunrise). They advertise their opening times as "Doors open on 10pm Saturdays" so I would tag that as straightforwardly as opening_hours=Sa 22:00-06:00 (or maybe even as opening_hours=Sa 22:00-sunrise. (The club is also open on Fridays and Sundays, but that's beside the point.) --seav 23:33, 4 November 2012 (UTC)
By the way the opening_hours discussion started more than 3 years ago. Since then many people have used that scheme even if it was not "officially" adopted, and not your wrapping scheme, based on some searches on taginfo For example: Take this POI. Its tag of opening_hours=tu-su 19:00-01:00 would hardly mean that the establishment was open on Tuesday at 12:30am or that it is closed on Monday at 12:30am. I think we can easily see that the mapper intended that the store opens at 7:00pm and closes at 1:00am the next day from Tuesdays to Sundays. If you want your time domains proposal to be very similar to opening_hours=*, then you'd better consider the existing data. --seav 23:46, 4 November 2012 (UTC)
I changed the wrap to next day now, and added some explanation on how to treat the wrap, please have a look at it. The wrap rules now appear quite natural to me, and the implementation is half-way decent. -- Eckhart 08:35, 5 November 2012 (UTC)
Looks good now. Thanks for considering my comments. --seav 22:21, 5 November 2012 (UTC)

Bi-weekly Parking

In Belgium you have many streets were you allowed to park on only one side. This side changed on the 1st and 15th of each month. Would it be possible to express those periods 1-15 and 16-31 with time domains ?

This has been possible before, although quite lengthy. However, I just added a day specifier that shortens your use case a lot:
day 1-15 00:00-24:00 and day 16-31 00:00-24:00.
-- Eckhart 19:11, 21 January 2013 (UTC)

Existing implementation

You may want to have a look at

Human understandable and formal specifications, a lot of examples, a client side JavaScript implementation and a server side PHP implementation. You may even interactively evaluate time_domain expressions. Would be nice if the proposed feature is based on this specification, because this will reduce the effort needed to adapt the implementations.

--Netzwolf 00:33, 22 January 2013 (UTC)

As you might have guessed, I had a look at your specification before writing the proposal. Here are some comments on your extensions:
  • Cooperative values: I don't think this is a good idea: just have a look at the list of opening_hours values I created. Judging by a random sample, most of the values which you want to interpret as "coorporative" are probably not intended as cooperative values.
  • Time is not optional any more: already in the proposal
  • Daywrap: already in the proposal
  • Date ranges: you state that "Date ranges must be terminated now with a :. This prevents difficult to resolve ambiguities." However, there are no ambiguities in the proposal, and lots of opening_hours values would become invalid.
  • Plain text information: I think adding this is a big mistake; you're mixing up semantic and non-semantic data, you restrict presentation to textual information and ignore localisation issues.

-- Eckhart 07:18, 22 January 2013 (UTC)

Actually I think that that "plain text information" is a very good concept, which can handle many real life situations like open only if reserved in advance, special instruction to get in, corner cases like "in sunny conditions only" etc. etc. Sure it is has problem with localization, but this is true to all plain text information no matter how you make the syntax - even names have this poblem.

"n"th weekday in a month

How I could write "n"th weekday in a month?

e.g. Many barbers are absent 2nd, and 4th Monday, in Japan.

as following this page,

opening_hours = Mo[24] off


Right now, the proposal does not contain any special syntax for "nth weekday in month". However, it is perfectly possible to express "closed 2nd and 4th Monday of the month" as day 8-14,22-28 Mo off off.-- Eckhart (talk) 18:09, 2 February 2013 (UTC)


The example opening_hours=20:00-03:00; Mo off is not evaluated by opening_hours.js as described. opening_hours.js does follow the rules and only sets the entire Monday to closed. Everything else should be handled as described on the page. --Ypid (talk) 18:15, 26 October 2013 (UTC)

open ranges

Please add support for open ranges, this can be used in many cases. --Jakubt (talk) 00:51, 27 January 2014 (UTC)

Do you mean open end? If not, please explain what you mean. Please also refer to the specification to see what is already supported.--Ypid (talk) 20:04, 18 September 2014 (UTC)

ISO standard

You might want to look at the ISO standard that defines time ranges and durations:

And derive something out of it --Vanuan (talk) 14:31, 17 September 2014 (UTC)

Or simply use it. For the end user you need a converter.
The big advantage of using a norm is that plenty of widgets or code already exist.
For opening_hours, click on the textual representation to have it in a more human friendly way: Sep-Jun 12:00-14:00,19:00-21:00; Sep-Jun Tu off; Jul-Aug 12:00-21:30.
If duration is stored as... duration, then computing is far easier. --Nospam2005 (talk) 20:47, 19 July 2017 (UTC)