Be interoperable with schema.org

[Alexandre Segura]

Hi,

Thank you for this library.
I'm planning to use it to replace our own implementation.

We are using the schema.org openingHours string notation.

Would you be interested into a parser? I will need to write one in any case, so I can just contribute it here.
This was rejected previously (#62), but maybe you have changed your mind? 🙂
Also, it could be a nice way of serializing a OpeningHours object in database as a simple string (#126)

Let me know.

[Kyle]

Hi,

We actually have the reverse compiler method: asStructuredData() which has been specifically implemented to match the schema.org openingHours notation. So it could make sense to also have a way to parse it. But maybe it does not need to have a strong dependency with the OpeningHours library as it would suffice to create a function that would parse the string and return an array-definition compatible with the OpeningHours::create() input. Such as:

schemaOrgStringToArray('Mo,Tu 09:00-12:00,13:00-18:00')
// would output:
[
    'monday'  => ['09:00-12:00', '13:00-18:00'],
    'tuesday' => ['09:00-12:00', '13:00-18:00'],
]

I would be glad to either merge a pull-request and help for that whether it would be a OpeningHours method or an other composer package and an edit of the OpeningHours README to show how to use this package to create an instance from the schema string.

About serializing opening hours to store it in DB, we have "exceptions" and "data" keys that would not fit the notation and would be lost, and there is yet the needed tools natively in PHP to store all the data wit no loss, so I would not recommend to use this string notation to store it, and I explained (a few times yet) why it's not relevant to have it in the library IMO:
#147 (comment)
#126 (comment)
#60 (comment)
#154 (comment)

To summarize it:

• It's way better to store days/times in several dedicated tables to get a real benefit of having it in a DB.
• OpeningHours does not create any particular relevant state, ideally you should pass all the data at once as an array in the constructor, and so it just provides methods that use the data you provided. So what you should store and serialize if you really want to zip it as a single string value, is the array you actually gave to OpeningHours, and this array can be serialized with any function you want (serialize/json_encode/var_export), no need for an extra serialization method, PHP has yet way enough native functions for that.

Thanks

[Alexandre Segura]

Thank you for your detailed answer.

Yes, this openingHours string format is not the best to store in database, and is a little mess to parse.
But you know... legacy 😅

It's a long story, but we used openingHours at the very beginning, because we used some kind of code generator based on schema.org. This asStructuredData method is perfect, this would allow fixing coopcycle/coopcycle-web#412

About "exceptions" (holidays), we store them in a separate table actually.