search

nhsconnect / gpconnect-provider-testing

GP Connect automated test suite for API providers
Apache License 2.0
11 stars 5 forks source link

Appointment Features Test using different time zones (and so over 14 days) #313

Closed KevinMayfield closed 4 years ago

KevinMayfield commented 4 years ago

The start and end dates are using different time zones which makes the difference between start and end over 14 days.

So should be rejected according the to GP Connect spec.

Example url parameters [Method = GET] [Path = /GP0001/STU3/1/gpconnect/Slot] [Query = ?start=ge2019-10-25T01%3A00%3A00%2B01%3A00&end=le2019-11-08T01%3A00%3A00%2B00%3A00&status=free&searchFilter=https%3A%2F%2Ffhir.nhs.uk%2FId%2Fods-organization-code%7CB81603&searchFilter=https%3A%2F%2Ffhir.nhs.uk%2FSTU3%2FCodeSystem%2FGPConnect-OrganisationType-1%7Curgent-care&_include=Slot%3Aschedule] Decode of this request = [Method=GET][Path=/GP0001/STU3/1/gpconnect/Slot][Query=?start=ge2019-10-25T01:00:00+01:00&end=le2019-11-08T01:00:00+00:00&status=free&searchFilter=https://fhir.nhs.uk/Id/ods-organization-code|B81603&searchFilter=https://fhir.nhs.uk/STU3/CodeSystem/GPConnect-OrganisationType-1|urgent-care&_include=Slot:schedule] " The start date 2019-10-25T01:00:00+01:00 is equivalent to 2019-10-24T23:00:00+00:00 in UTC (same time zone)

KevinMayfield commented 4 years ago

To work around we have changed our 14 day check to 15 days.

PeterGresty commented 4 years ago

The 1.2.3 release notes (https://developer.nhs.uk/apis/gpconnect-1-2-3/overview_release_notes_1_2_3.html) say: Clarify date / time component use in appointments Tickets: #646

Affects: Appointment Management

Description:

Clarify that Appointment, Schedule and Slot date/time elements (start, end, planningHorizon, created) to be populated in local time in the format yyyy-mm-ddThh:mm:ss+hh:mm, using timezone offset +00:00 for UTC and +01:00 for BST

Clarify Search for free slots start and end parameters may be:

dates in the format yyyy-mm-dd, or date and times in local time in the format yyyy-mm-ddThh:mm:ss+hh:mm, using timezone offset +00:00 for UTC and +01:00 for BST

So given you have one date in BST and one date outside BST then the +01:00 and +00:00 are appropriate and correct in the message, given that there is a clear requirement that the dates are formatted in this manner. Therefore I would expect that the provider system should be dealing with local time(BST) and also UTC as appropriate. So changing the check from 14 to 15 doesn't seem correct as spec clearly says : SHALL request a maximum date range covering a two-week period

KevinMayfield commented 4 years ago

Not occuring in the current timezone