1

in the database, I have a column that datatype is Date. I use ORM to map this DB, so, in the appropriate C# class, I have a field with DateTime datatype. From FHIR-client I receive a JSON document with a date formatted in ISO 8601 and it contains Time Zone. when I use conversion from string to DateTime I lose a Time Zone, and in the database, I store a date without a time zone. When FHIR-client asks me for some data it already sent to me, I read the DB and, of course, return the original date but(!!!) without Time Zone.

is there any workaround somehow to store the time zone from the original FHIR request?
I'm not able to modify the existing database because it's a mature old project and used a lot of these tables etc.

Hamed Moghadasi
  • 1,523
  • 2
  • 16
  • 34
JhonMalk199
  • 97
  • 1
  • 9
  • 1
    Is the timezone really necessary? Could your client accept UTC instead? – Ben Cottrell Feb 09 '20 at 09:25
  • 5
    Please provide more details - what database are you using? What's the field type in the database? Note that `DateTime` doesn't contain an offset - have you tried using `DateTimeOffset`? (It's also worth noting that despite the naming in ISO-8601, there's no format in ISO-8601 that actually contains a time zone identifier - only a UTC offset. It's unfortunate that the standard confuses the two.) Fundamentally though, if you're storing the data in a database field that doesn't contain an offset, that original information is gone. – Jon Skeet Feb 09 '20 at 09:25
  • unfortunate there is no way to fetch timezone from `DateTime`. 'Cuz `Datetime` does not store time zone information. – Hamed Moghadasi Feb 09 '20 at 09:44
  • You have two options if your database does not support storing timezone with `DateTime` type columns. 1) Store your TimeZone in another column with main column storing data in UTC 2) Store `DateTime` in string. – MKR Feb 09 '20 at 10:01
  • Oracle database, columns "IDENTIFIER_PERIOD_START" type: DATE, "IDENTIFIER_PERIOD_END" type: DATE etc – JhonMalk199 Feb 09 '20 at 11:08
  • You should always store a date in a database as DateTime object and not as a string. Then the UTC time is automatically saved so you can always return a timezone with the request. You are nort loosing the timezone. The default display method in Net Library is to display in local timezone. If you compare the original string time to the displayed value you will see the time is not always the same if the source was in a different timezone. – jdweng Feb 09 '20 at 13:31
  • Like Jon said, we need more details, but also in most database I know, a `date` data type is just a date (year, month, day). There is no time component. Thus, time zone is also irrelevant. Please be more specific about exactly what database platform, confirm the types, which ORM, and give us examples of your input data, output results, and what you expected. Thanks. – Matt Johnson-Pint Feb 09 '20 at 18:03

1 Answers1

2

The FHIR type is the offset, not the time-zone.

So essentially if you don't have an option to store the offset into the database, you will need to make an assumption on what that value is inside, and make your code handle that, adding the offset value when needed. Date only types in the FHIR client don't need the time (or zone) on them, but I'm assuming you're referring to datetime fhir properties.

There are some extension methods on DateTime and DateTimeOffset c# classes that can help you with coding these assumptions in (.ToFhirDate() and .ToFhirDateTime(offset))

https://github.com/FirelyTeam/fhir-net-api/blob/355c8ece1bdc81cd6354dd7c7f01381a5d99725d/src/Hl7.Fhir.Core/Support/DateExtensions.cs#L32

Forcing all the values to UTC is one method, but if your database isn't expecting that, then you're going to further confuse things.

Brian Postlethwaite
  • 184
  • 5