For example, something that would otherwise parse to:

[{"day": "sunday", "opens": "09:00", "closes": "17:00"}, {"day": "sunday", "opens": "17:00", "closes": "19:00"}]

would automatically get merged into:

[{"day": "sunday", "opens": "09:00", "closes": "19:00"}]

List = Monday, Wednesday, Friday
Range = Monday - Wednesday

Both = Monday, Wednesday – Friday

this would resolve to Monday, Wednesday, Thursday, Friday

This is an issue for compiling a list of breaking API changes that would be nice to have, but arent really worth doing on their own. The plan is to save them all up and apply them all at once whenever version 1.0 is considered ready.

The list:

• rename the model classes to have more descriptive names
• give all the model classes a consistent API (and maybe create some superclass or interface for this?)
  • make the parse() methods on each class generic (using fields and methods defined by the model classes) and pull it up into a superclass for deduplication
• convert the constructor of the Days class to a class method from_range and make a simpler constructor (this will require some pretty major refactoring)
• #3
• rename Times to TimeRange and create a class Times that can store multiple TimeRange's similar to Days (see #5)
• make is_24_hr() and is_12_hour() in Time consistent
• create a common system for specifying assumptions to make when the information is not available (for AM/PM, and century/year)
• make all the from_parse_results methods consistent with regard to if they are processing a clean dictionary or a pyparsing.ParseResult object and possibly rename them to from_parse_result_dict

a string like Tuesday’s has a single left-facing apostophe (’) in it, which is not the same as a "regular" straight apostrophe (').

Need to double check whether this is currently handled by the unicode normalizing or the pyparsing patterns and if not, handle it. Also, regardless, there should be a unit test to make sure that this doesnt become an issue later

if a data source is already partially formatted,like this:

"hours": {
	"friday": "700AM-400PM",
	"monday": "700AM-400PM",
	"sunday": "Closed",
	"tuesday": "700AM-400PM",
	"saturday": "730AM-400PM",
	"thursday": "700AM-400PM",
	"wednesday": "700AM-600PM"
},

then it would be nice to be able to just parse the time range.

this should be straighforward as tweaking the internal API so its consistent with the public one and making a new release.

just leaving it here as a TODO

• Times
• Time (?)
• Days
• Day

Despite having jsonify in the name, this is mainly a general parser for opening hours strings that can be made to output to pretty much any format.

Might be nice to swap to a new name early on

see: CAVaccineInventory/vaccine-feed-ingest#703

this might require renaming the newly-publicized Times class to TimeRange so Times can be used for multiple TimeRange's

Sometimes notes are included in opening hours strings:

By appointment
By appointment. Schedule in MyChartPLUS or by phone.
F: Hours Vary; By appointment; Clinics are usually held on Friday mornings. Time and location is usually to-be-determined the week of the clinic and subject to change. Individuals will be givien the location and time when scheduling appointment.
M,T,W: 9am-4pm; By appointment

Would probably be useful to find a solid way to detect these and make them available separately from the times themselves. Some problems this might pose:

• notes arent as universally structured as date or time ranges are
• associating notes with one specific day might require significant work given how multi-day handling is implemented

this would be similar to how pyparsing_common offers classifiers for things like ISO dates, but would include things like date strings "January 31st, 2021" etc

the schema from vaccine-feed-ingest supports this:

opening_dates: [
    {
      opens: str as date that facility opens in iso8601 format e.g. 2021-04-15,
      closes: str  as date that facility closes in iso8601 format e.g. 2021-06-15,
    },
    ...
  ],
  opening_hours: [
    {
      day: str as lowercase day of week e.g. monday,
      opens: str as time with facility opens on this day in format hh:mm,
      closes: str as time with facility closes on this day in format hh:mm,
    },```

2021-07-11T11:54:00.000+00:00

should be pretty easy since i think pyparsing supports this pattern already. Still need to figure out how to get it to work with the Classes for handling a specific date

this was originally made to comply with the schema for https://github.com/CAVaccineInventory/vaccine-feed-ingest, but it would be nice to allow a function to be passed that allows the values or structure of the json to be customized in advanced cases or if objects, rather than string results, are preferred

It would be nice to be able to pass in real-world opening hours data that may have some typos and have this library automatically handle that.

Maybe a more complex solution would be better but for now an easy solution to this would be to change some of the patterns that currently use CaselessMatch for parsing so they can tolerate a certain number of incorrect characters and still be considered valid.

This "ignore up to x typos" functionality does not currently exist in this specific class in pyparsing, although it exists in other classes (CloseMatch if i recall correctly). There is currently an open PR in pyparsing to add this functionality.