Open ajf2 opened 3 weeks ago
Thanks for raising this issue @ajf2 - we will investigate and report back.
On behalf of DfT:
@ajf2 could you provide an example of the content you are getting back from the events endpoint, please.
Of course, for brevity here's an edited copy of the response with all but the oldest of the 37 event records removed:
{
"events": [
{
"publicationTime": "2024-10-11T15:22:11.219736Z",
"traCreator": 15,
"currentTraOwner": 15,
"troName": "The Sample County Council (Prohibition of Waiting, Loading and Stopping) and (on-Street Parking Places) (Civil Enforcement Area) Consolidation Order 2019",
"regulationType": [],
"vehicleType": [],
"orderReportingPoint": [
"ttroTtmoByNotice"
],
"regulationStart": [],
"regulationEnd": [],
"eventType": "create",
"eventTime": "2024-10-11T15:22:11.219736Z",
"_links": {
"self": "/dtros/70a039b9-1917-4837-90d2-ed7338cf79b3"
}
}
],
"page": 1,
"pageSize": 37,
"totalCount": 37
}
The publicationTime
and eventTime
properties are both from before the clocks went back so I'd expect them to have +01:00
at the end instead of a Z
. As it is, I'm not sure if it means 15:22 British Summer Time or 15:22 UTC (which is 16:22 British Summer Time).
On behalf of DfT:
Thanks Adrian - we will come back to you shortly.
I've been trying out the
events
endpoint and on examining the response, I see timestamps such as"2024-10-11T15:22:11.219736Z"
. It's great that millisecond precision is there in case we create multiple events within one second and need to sort them chronologically, but it's not clear from the ICD whether the offset, theZ
at the end, is intended to signify timestamps in UTC as opposed to local UK time.Given that on the 11th October we in the UK were observing daylight saving time, I would expect this offset to read
+01:00
. Is this timestamp supposed to be a UTC timestamp (meaning 16:22 UK time which on that day is the same instant of time as 15:22 UTC), or is this timestamp supposed to be UK time already (in which case the offset is incorrect and should be+01:00
instead ofZ
)?The User Guide states, in relation to Regulations, "All times are expressed in local time (i.e. without reference to UTC time-zone offset)" and "all date and time records shall be expressed using the ISO 8601-1:2019 extended format (e.g., YYYY-MM-DDTHH:MI:SS) – note: no Z time zone offset.". This seems fine based on my current understanding, as I'm not sure any properties under Regulation need anything more precise than a simple date only component, or time only component depending on context.
Could you please clarify how time zones and UTC offsets are to be used within the D-TRO Service? As a side question, is the system ever expected to be used in other time zones, such as in Gibraltar?