Wikidata:Property proposal/checkin and checkout times

Checkin and checkout times

checkin time

Not done

Description	The earliest time at which a reserved room in a hotel, inn or lodge is available to an arriving voyager.
Data type	String
Template parameter	checkin in voy:Template:Listing Template:Listing (Q14330485), in voy:Template:Sleep (Template:Sleep (Q14330740)
Domain	WikiVoyage listings
Example	⟨ Hotel California ⟩ checkin time Search ⟨ 12PM ⟩ or ⟨ Carthage Inn ⟩ checkin time Search ⟨ 1PM ⟩
Source	per WikiVoyage formatting guidelines

Comment I don't think the pending datatype will be available anytime soon. Conversion, if ever necessary, should be made easy.
--- Jura 09:43, 15 May 2016 (UTC)[reply]
Comment I'm unsure why you include "Hotel California" in the text. This is a time of day or a time range, so a B&B might have checkout:11AM checkin:3-9PM and a hotel with a 24-hour desk clerk checkout:11AM checkin:3PM with no "latest" time to check in. K7L (talk) 19:01, 15 May 2016 (UTC)[reply]
- It's a (fictional) sample item. Ideally the sample would be an item for an actual hotel with its actual time there.
  --- Jura 04:50, 16 May 2016 (UTC)[reply]
Please provide a real example. Please explain how variable checkin (e.g. by payment of a premium) will be recorded. Please provide a description. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:27, 16 May 2016 (UTC)[reply]
- Oppose as string; needs structured data. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:28, 16 May 2016 (UTC)[reply]
- Comment There is currently no Wikidata type for a standalone time of day (hh:mm AM/PM) without associated date. Creating this with a type that doesn't exist is only going to delay or block its implementation. Even if the datatype did exist, this may need to be a range (checkin between 3-9PM, for instance) if an establishment has no 24-hour desk clerk. voy:Carthage (Missouri)#Hotels looks straightforward enough "Check-in: 2PM, check-out: 11AM" but get down to the little motel which has only restored and re-opened five of its rooms and the odds are there will be no one at the front desk at 2AM if you arrive late. K7L (talk) 20:02, 16 May 2016 (UTC)[reply]
  - If we need to wait for a datatype, so be it. Ranges are probably best dealt with by having two properties, say "earliest checkin" and "last checkin". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:21, 17 May 2016 (UTC)[reply]
Support my proposal
--- Jura 06:10, 17 May 2016 (UTC)[reply]
- As you have been told many times, you don't need to support your own proposals. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:21, 17 May 2016 (UTC)[reply]
Support K7L (talk) 13:07, 17 May 2016 (UTC)[reply]
Comment. We should create an item for every single minute of a day. Thierry Caro (talk) 11:01, 20 May 2016 (UTC)[reply]
- . Even if we would, entering hh:mm would be easier for users. Jura 11:08, 20 May 2016 (UTC)[reply]
  - What else would you enter with my method? Thierry Caro (talk) 11:58, 20 May 2016 (UTC)[reply]
    - Q220050000 ? At least in QuickStatements. Inclusion in the listing editor would also be more complicated. -- Jura 12:21, 20 May 2016 (UTC)[reply]
      - Ah! OK. Thierry Caro (talk) 12:27, 20 May 2016 (UTC)[reply]
Oppose per my comment below on checkout time. And anyway, it should be in 24 hour notation, not in 12 hour AM/PM notation. --Izno (talk) 10:20, 22 May 2016 (UTC)[reply]
Oppose either await new datatype or use items. Using string datatype doesn't take into account the many different time formats in the world. --Pasleim (talk) 15:14, 24 June 2016 (UTC)[reply]
- @Pasleim:: Would you have a sample where this can be problematic? Ideally an actual one from Wikivoyage.
  --- Jura 13:20, 7 July 2016 (UTC)[reply]

The problem is that each user will insert the time in a different format. I can write 05am, 5am, 5a.m., 5 a.m., 5a, 5A.M., 5:00, 05:00, 5.00, 5 Uhr, 0500, etc. --Pasleim (talk) 13:39, 7 July 2016 (UTC)[reply]

So we just need to define filter and formatting constraint, as we do with other string properties? I don't see this as insurmountable problem.
--- Jura 13:52, 7 July 2016 (UTC)[reply]

Do you think we will be able to agree on one format? --Pasleim (talk) 14:25, 7 July 2016 (UTC)[reply]

We can fix it beforehand or do as we usually do: build constraints based on the input.
--- Jura 17:06, 7 July 2016 (UTC)[reply]

I prefer if we fix it beforehand. --Pasleim (talk) 14:51, 12 July 2016 (UTC)[reply]

Oppose For having strings that contain non-ISO 8601 formatted time. ChristianKl (talk) 16:55, 7 July 2016 (UTC)[reply]
- You'd prefer 24h notation?
  --- Jura 17:06, 7 July 2016 (UTC
  - Yes, sticking to the the international standard for formatting time makes it easier both for non-American's to interact with the data and makes it easier for computers to interact with the data. ISO 8601 also deal with the way time zone information should be written if someone wants to include it. ChristianKl (talk) 17:35, 7 July 2016 (UTC)[reply]
    - Has this been found problematic at Wikivoyage? Are there cases at Wikivoyage where the later was needed?
      --- Jura 04:40, 8 July 2016 (UTC)[reply]
      - Currently it seems like time in Wikivoyage are individually entered in every language and not automatically copied from language to language. That means that the problem of conversion between standards isn't a big issue. However if you want to include times written in Wikidata in languages that have no AM or PM or their equivalents to AM and PM aren't AM and PM the issue get's more complex. ISO 8601 time is on the other hand language independent. Apart from that following international standards for which standard bodies have found consensus is a matter of principle. ChristianKl (talk) 08:01, 21 July 2016 (UTC)[reply]

Not done No consensus. Lymantria (talk) 07:00, 4 August 2016 (UTC)[reply]

checkout time

Not done

Description	time of day, 00:00 AM/PM, the latest time a voyager may check out of a hotel or lodge without incurring additional cost
Data type	String
Template parameter	checkout in voy:Template:Listing at Template:Listing (Q14330485), in voy:Template:Sleep (Template:Sleep (Q14330740)
Domain	WikiVoyage listings
Allowed values	per WikiVoyage formatting guidelines
Example	⟨ Carthage Inn ⟩ checkout time Search ⟨ 11AM ⟩ from voy:Carthage_(Missouri)#Hotels

Comment linked to preceding proposal "checkin time".
--- Jura 09:43, 15 May 2016 (UTC)[reply]
Please provide a (real) example. Please explain how variable checkout (e.g. by payment of a premium) will be recorded. Please provide a description. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:29, 16 May 2016 (UTC)[reply]
- Oppose as string; needs structured data. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:29, 16 May 2016 (UTC)[reply]
Neutral, due to the issues mentioned by Andy. Regarding the missing time property, we could constraint the string to \d\d:\d\d so that a bot could convert this property, once we have that datatype. --Srittau (talk) 17:51, 16 May 2016 (UTC)[reply]
- Conversion should indeed by trivial. A format constraint should ensure that it is structured data.
  --- Jura 18:06, 16 May 2016 (UTC)[reply]
Support K7L (talk) 13:07, 17 May 2016 (UTC)[reply]
Oppose as string, Support as item, with a set of bot-created new items for every minute of a day. Thierry Caro (talk) 11:10, 20 May 2016 (UTC)[reply]
- Sorry that I found your suggestion somewhat funny. It would solve localization issues. If we do that, we would need to add a property to these items to define a numeric value for the time.
  --- Jura 11:37, 20 May 2016 (UTC)[reply]
  - To tell you the full story, I once considered creating Wikipedia articles for each of these minutes. The template is already ready on the French Wikipedia! Wouldn't it be awesome to get to know everything that happened at 1:27 AM local time throughout history? Whatever, we already have some articles for specific dates on the French Wikipedia, such as January 27, 1897 (Q16025345). If we were reasonable, point in time (P585) would link to those items. But there are only a few hundreds for the moment, compared to the potential tens of thousands that we may have. Minutes of the day are much less numerous. It should be OK. Thierry Caro (talk) 12:07, 20 May 2016 (UTC)[reply]
    - The item should definitely have P585. I had thought once of something similar, at least for date-items. We could do a project for this? This needn't be linked to checkin/checkout. -- Jura 12:25, 20 May 2016 (UTC)[reply]
      - There is indeed enough material for a project. Dates and hours need time! They come in different forms, such as first Monday in August (Q14914714) and most of the time we don't have all the possible items, only a few. The thing is this is something for bot masters and I am not one. Maybe with QuickStatements? Thierry Caro (talk) 12:35, 20 May 2016 (UTC)[reply]
Oppose the item implementation above and separately oppose the non-structured original proposal. Time, separate from a date, is probably a necessary data type and we should propose as such to the developers. --Izno (talk) 10:19, 22 May 2016 (UTC)[reply]
- This had been done years ago, but apparently can't be implemented. As said, conversion should be straight-forward as formatting should ensure structured timevalues.
  --- Jura 10:47, 22 May 2016 (UTC)[reply]
  - Can't != haven't. And I am seriously skeptical that "can't" is the right phrase. --Izno (talk) 14:55, 23 May 2016 (UTC)[reply]
- Can you suggest an alternate approach with a reasonable implementation timeframe?
  --- Jura 17:34, 23 May 2016 (UTC)[reply]
  - That's not my job and it certainly isn't a requirement for this process. The reasonable alternative is to wait for the correct data type, period. --Izno (talk) 08:57, 24 May 2016 (UTC)[reply]
    - No, obviously you are free to cast your vote. I was just hoping for constructive input helping us find a solution.
      --- Jura 09:05, 24 May 2016 (UTC)[reply]
Oppose per my reasons above --Pasleim (talk) 15:15, 24 June 2016 (UTC)[reply]
Oppose For having strings that contain non-ISO 8601 formatted time. ChristianKl (talk) 16:53, 7 July 2016 (UTC)[reply]

Not done No consensus. Lymantria (talk) 07:00, 4 August 2016 (UTC)[reply]