I updated to the latest version 18.104.22.168 and it works great, thank you! we'll trigger an update at the practice once the 19.x version goes into a stable release and we have our integration work ready.
However, there still is a nuisance
I tested the API for dates ("yyyy-MM-dd") and realized that you support timestamps as well ("yyyy-MM-dd'T'HH:mm:ss").
I tested the following border-case and the results are IMO still not 100% correct:
Code: Select all
Note the less or equal value is 2019-06-11T14:00:00 and I'm getting (and shouldn't) an appointment entry whose:
and should not be the case because the "le" timestamp should correspond to the "end" and not the "start" of the appointment. Likewise the "ge" should correspond to the "start" of the appointment.
Since this request also takes into account dates (without the timestamp part) then it should be consistent and consider a given date le2019-06-11 to be equivalent to le2019-06-11T00:00:00 which means it should not return the appointments for that date as it currently does.
Possible clean solutions:
* Accept dates only ("yyyy-MM-dd") and not date times, in which case the current impl is correct.
* Accept date-times too ("yyyy-MM-dd'T'HH:mm:ss") but then implement it correctly => ge filters by the start of the appointment, le filters by the end of the appointment and finally consider the date truncation issue as well.
These nuisances or border-case inconsistencies may result in a Web widget presenting the user with blocked times per day and showing blocks that are before or beyond the given range. Then the front end would have to trim these broken border cases.