Proposal talk:Time domains

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? Craig.za (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. Craig.za (talk) 12:07, 21 August 2015 (UTC)

Wrapping time intervals

Resolved

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 http://www.netzwolf.info/en/cartography/osm/time_domain/

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, http://www.netzwolf.info/en/cartography/osm/time_domain/explanation

opening_hours = Mo[24] off

right?

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)

Changes

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:

http://en.wikipedia.org/wiki/ISO_8601

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)

Point in Time

Shouldn't a Point in Time be YYYY MM DD hh:mm ? Just hh:mm is merely a time, not a Point in Time. Since this proposal is mainly to extend opening_hours for use with conditional it would be far more appropiate too. It allows to specify a period PiT-PiT, like 2018 Dec 25 08:00-2019 Jan 1 00:00 for a road beeing closed during the Christmas hollidays.

BTW: Why would 'Mo-Fr 08:00-12:00; 14:00-20:00' in your example be wrong? The shop is open from 14:00-20:00 everyday and additonal from 08:00-12:00 during weekdays. --Noordfiets (talk) 06:59, 6 August 2018 (UTC)

Vague definition of holidays

The current proposal has two types of holiday, public and school holidays, but this is vague at best, and can't be universally applied. What exactly does a public or school holiday constitute? Would an OSM client wishing to parse holiday data have to parse school district closures or public holidays for the local government? Many businesses in the US close on Thanksgiving and Christmas, but not on Memorial Day or MLK Jr. Day; how do we know what the business considers a holiday worth closing for? Even worse, the current way of expressing holiday hours leaves no room for religious holidays that fall outside of the status of official in the country a business is in. For example, a Jewish business in a majority non-Jewish area might be closed on Yom Kippur, but not on Christmas, which would differ from the norm for a public holiday in that region (in addition, Jewish holidays don't follow a gregorian calendar, and such aren't easily expressable using simple gregorian dates). I'm not sure how this could be handled, but I think the current method of holiday expression is sloppy at best.

Possibly a system expanding on the current one could be used, either with groupings of holidays, or with specific holidays having their own codes. Possible groupings of additional holidays (which may differ from just PH or SH) might be something along the lines of CH, MH, JH, and HH for Christian, Islamic, Jewish, and Hindi holidays, respectively (as an example, the list would need to be longer for real use). Codes for each holiday could also be used, though this might be cumbersome.

--Avnt (talk) 18:26, 7 July 2023

1. This is not "the current proposal". You are looking at the wrong one from a decade ago. Key:opening_hours made it clear it's Key:opening hours/specification being the standard.
2. It's defined in https://github.com/opening-hours/opening_hours.js/tree/master/src/holidays by implementation. Define them yourself.
3. There's no solution for holidays based on non-Gregorian calendars yet. opening_hours=easter is the only variable date item calculated by an algorithm [[2]] despite the function being named getMovableEventsForYear().

—— Kovposch (talk) 07:22, 16 July 2023 (UTC)