Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When receiving times from a JCC GPLAN backend, all times are in the evening because the comparisons are against Unix epoch. The intended comparison was probably against e.g. midday + unix_date.
The latter comparison would (I believe) result in a 1 h offset for afternoon/evening due to DST in summertime. Attached patch simply looks at the hour component of the time.
Comments
Comment #1
frankschaap CreditAttribution: frankschaap commentedI wonder what the solution is to get this working in Almelo, because it appears to be working there.
And yes, we need to use some weird offsets to for Qmatic in Vught. Hearing about your case makes me wonder if these systems even use timezones... so far we have not even needed to adjust for DST o_0
Comment #2
Heine CreditAttribution: Heine at LimoenGroen for Historisch Centrum Overijssel commentedIn Almelo, I guess +unix_date was added to the comparison. Anything past 17:00 is marked as evening there however, which I believe is not expected and due to DST differences between January and June. Coming October Almelo will probably start showing the slot 17:00 - 18:00 as afternoon again.
Do you happen to have a dump of values received in webform_appointment_date_time_element_process() from a Qmatic backend? I would assume both client adapters would result in identical datetime formats.
Comment #3
Heine CreditAttribution: Heine at LimoenGroen for Historisch Centrum Overijssel commentedScratch that :)
Evening is derived from new DateTime('1970-01-01 17:00', $timezone);
So, evening means anything after 17:00. Is that correct? I would expect 18:00 as the cutoff.
Comment #4
frankschaap CreditAttribution: frankschaap commentedRegular opening hours are 9-17. So yeah, for the municipality evening opening hours are > 17:00.
Comment #5
frankschaap CreditAttribution: frankschaap commentedSticking to the organisation's interpretation of time of day may in fact not be the most clear and productive way to service the customer. Should we reconsider?
Comment #6
Tess Bakker@Heine,
or
edit: my mistake, didn't notice the new comments today
Comment #7
Tess BakkerYou can make a variable for morning, midday and evening with as default the official standaards.
Comment #8
Heine CreditAttribution: Heine at LimoenGroen for Historisch Centrum Overijssel commentedAttached patch introduces variables.
Comment #9
Tess BakkerNice, only the variables will be called every run inside "foreach ($dates as $date => $time_array)"
Comment #10
Heine CreditAttribution: Heine at LimoenGroen for Gemeente Venlo commentedIndeed.
Comment #11
Tess BakkerWorks perfect!
Comment #12
Tess BakkerComment #13
Heine CreditAttribution: Heine at LimoenGroen for Gemeente Venlo commentedMoving to fork.
Comment #14
MrHaroldA CreditAttribution: MrHaroldA commentedNeeds reroll because of the rebranding ...
Comment #15
ralphvdhoudt CreditAttribution: ralphvdhoudt at ezCompany commentedBetter patch, now against dvg appointments
Comment #16
MrHaroldA CreditAttribution: MrHaroldA commentedBack to RbtC since there were no changes, except for using renamed functions.
Comment #18
MrHaroldA CreditAttribution: MrHaroldA commented