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

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

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"}]

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 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

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 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

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.