---
# System prepended metadata

title: '**GD-1541**'

---

# **GD-1541**

## **Quicksilva ():**

*Documenation:*
 - Creates a full date from the System.DateTime object
 - Creates a date based on full or partial date supplied as a string. Please note, dateValue must be in the format of YYYY, YYYYMM or YYYYMMDD




## **MIG Vision / Emis (UTC):**

*1st Response from the support service:*
Patient trace birthdate: Vision - 1931-08-23
Patient trace birthdate: Emis - 1951-01-28

*2nd Response from the support service:*
UTC

*From EMIS Portal SDK specification:*
 - things like requestTime and responseTime (used for logging) are in UTC:
```
<xs:attribute name="responseTime" type="xs:dateTime" use="required"> 

<xs:annotation> 

<xs:documentation>The UTC time at which this response was generated</xs:documentation> 

</xs:annotation> 

</xs:attribute> 
```
*From Final Data Set and Data Items JUYI phase one V3.9:*
 - for date fields like 'Date', 'RelatedPerson.birthDate', 'RelatedPerson.period.start': 
```
event.effectiveTime.value
Should already be in 'YYYY-MM-DDTHH24:MI:SS' format
```
 - for Medicines 'CompletionDate':
 `event.medication.expiryDate`

**TPP Community / GP ():**
-
*Integration:*
- logging - UTC
- CSV -> db - naive datetime

*Documenation:*
*From Final Data Set and Data Items JUYI phase one V3.9:*
 - for Date field in Clinical observations & finding: 
```
SRCode.DateEvent
```
- for Medicines 'CompletionDate':
```
SRPrimaryCareMedication.DateMedicationEnd
```

**Rio (UTC):**
-
*Documenation:*
 - DateTime ( DD-Short Month-YYYY , for example 17-Jan-2017)
 Dates and times must be passed through according to one of the following formats:
 

| Dates only | YYYY-MM-DD |
| -------- | -------- |
| Date and time     | YYYY-MM-DD HH:MM+ZZZZ     |
|                   | YYYY-MM-DD HH:MM:SS+ZZZZ     |
|                   | YYYY-MM-DD HH:MM:SS.fff+ZZZZ     |
| Time only         | HH:MM+ZZZZ |
|                   |      HH:MM:SS+ZZZZ |
|                   |      HH:MM:SS.fff+ZZZZ |

Times must be sent to the API in 24-hour format and must include a timezone offset.  Similarly, any times returned by the API will also include a timezone offset and be specified in 24-hour format.  This format will allow for an unambiguous time to be exchanged regardless of whether daylight savings is in effect or not.

For example, 10:30pm GMT on 5 Jan 2013 would normally be sent as “2013-01-05 22:30:00+0000” but if sent as “2013-01-05 23:30:00+0100” would be correctly interpreted.  Similarly 10:30pm BST on 23 July 2013 may be sent as either “2013-07-23 22:30:00+0100” or “2013-07-23 21:30:00+0000”.

**Adastra ():**
-
*Integration:*
https://github.com/KainosSoftwareLtd/gccg.velocity.etl.sourcedataextraction/blob/develop/Adastra/source/modules/processor/adastra_s3_service.py#L36
 - naive datetime

*Documenation:*
No information


**Liquidlogic ():**
-
*Integration:*

https://github.com/KainosSoftwareLtd/gccg.velocity.etl.sourcedataextraction/blob/develop/LiquidLogic/source/modules/utils/date_parser.py
 - naive datetime

*Documenation:*
 - The format of the date data type is follows: CCYY-MM-DD (e.g. 2011-03-17) 
- The format of the dateTime data type is follows: CCYY-MM-DDThh:mm:ss (e.g. 2011-03-17T10:20:23) 


**Trakcare (UTC):**
-
*Integration:*

 https://github.com/KainosSoftwareLtd/evolve.velocity.integration.iguana/blob/VIN-329-HL7-to-FHIR-New/shared/HL7v2%20to%20FHIR/mapUtils.lua
 > os.time{year=t.year, month=t.month, day=t.day, hour=t.hour, min=t.minutes, sec=t.seconds}
 - local time
 
*Documenation:*
- HL7 YYYYMMDDhhmmss format - UTC
