Structured hours for open and close times

[jungshadow]

On any element that this applies (e.g. polling_location, early_vote_site), this will allow officials to provide machine-readable hours to data consumers. However, most location hours are largely unstructured partially due to the intake mechanism (i.e. election system) and the hours themselves (i.e. some are by appointment only or vary greatly from day to day). A few related questions:

• Are there states that designate location hours at the state level and do those rules hold for municipal elections, as well?
• In lieu of state regulations, are there simple systems that would allow counties to manage the locations and hours, reduce administrative burden, and provide data in a more structured format?

High level of difficulty to tackle, but worthwhile if it can be accomplished.

[jktomer]

Lessons learned from collecting structured polling hours (independently of VIP) for early voting in 2014:

• Time zone information definitely needs to be specified explicitly per polling location. Otherwise you run into painful cases like Phenix City, AL -- whose municipal government runs on Eastern Time despite the fact that AL is officially in Central Time -- where it's impossible to correctly interpret any hours that are just specified as "local time."
• Because the fall DST boundary often occurs during the early voting period, time zones further should be specified in a way that accounts for DST. Suggested formats:
  • ISO 8601 ("08:00-05:00" for 8AM Eastern Standard Time), attached to each individual time specification. Pro: precise and easy to interpret and validate without reference to any external database. Con: somewhat obscure; repetitive (since zone info has to be attached everywhere a time is specified); requires breaking entries for repeated daily schedules up at the DST boundary, if applicable
  • tzdb syntactic ("EST5EDT"). Pro: can be specified once for an entire location. Fairly easy to read and write. Con: untrained users may still find it pretty opaque. Hard to validate (to distinguish right from wrong values requires the tzdb, so it can't be done in an xml schema validator).
  • tzdb symbolic ("America/New_York", "America/Los_Angeles", "America/Metlakatla"). Pro: can be specified once for an entire location. Easy to interpret, even for untrained readers. Con: easy to mess up when writing, hard to validate.
• Schedules are described in a variety of bizarre ways ("from 10/7 to 10/21, open Mondays, Wednesdays, and Fridays from 9am to 5pm and Tuesdays, Thursdays, and Saturdays from 8am to 7pm, with a lunch break from 11:30am to 12:30pm; from 10/22 to 11/1, open daily from 9am to 1pm. But on 10/31, disregard the above -- hours are from 10am to 12pm only"). The simplest option is not to support repeating schedules at all, and explicitly specify open and close times for each day separately. The next-simplest option -- supporting only contiguous date ranges -- is next to useless for compression purposes and only makes the standard more complicated. To achieve substantial compression you really need to support both date ranges and day-of-week-based scheduling within the ranges. I don't think this is worth it.
• "or by appointment" is a valuable piece of information to add for dates where by-appointment voting is available (whether or not regular hours are also available).

[courtney-rosenthal]

For the VoteATX application (not VIP), I express polling times as an enumerated sequence of (open..close) ranges (each range spanning time contained in a single day). This facilitates database queries to get "best voting place for me right now" type operations.

[pkoms]

Two other considerations:

1. An office can have constrained hours and be open by appointment only. (e.g., "The office is open by appointment only between 6-8 on Tuesdays.")
2. Some office hours are subject to change on the whim of the authority -- and there's good reason for this, since it's useful for authorities to be able to expand their open hours later on if they find high demand early in the voting period. Moreover, it's at least somewhat predictable what hours could potentially change: e.g., where hours are state-mandated, we know they won't change. It could be useful to have a "subject to change" flag?

[jungshadow]

Moving this into 5.0 since we seem to have some general consensus on this.

[jungshadow]

Closed by #31