Stream: terminology
Topic: timezone codes
Eric Haas (Aug 27 2019 at 15:44):
I would like to add timezones as a meta tag as a precurser to a proposal to add new meta TZ element in R5. Looking into this it looks like this is what I want
Eric Haas (Aug 27 2019 at 15:44):
"system" : "https://www.iana.org/time-zones", "code" : "PDT", "display" : "Pacific Daylight Time"
Eric Haas (Aug 27 2019 at 15:48):
Thing is I have not really looked at the codesystem that closely. I am hoping there may already be some pre-existing work in this area since it looks like several coding languages use it. So I am asking, does anybody have this code system in FHIR or some format that is an easy peasy conversion?
Brian Postlethwaite (Aug 27 2019 at 21:35):
This is not what you usually find. The tz database contains values like 'Australia/Melbourne" or 'Europe/Monaco'
Grahame Grieve (Aug 27 2019 at 22:11):
carumba the timezone database is a complex mess; making a code system representation for that is going to be a big project
Brian Postlethwaite (Aug 27 2019 at 23:14):
Just like the languages?
Brian Postlethwaite (Aug 27 2019 at 23:16):
I would expect the code system to just manage the values, not all the properties, there are many libs around for that, together with all the other logic manipulation and historical contexts.
Grahame Grieve (Aug 27 2019 at 23:16):
much worse - someone already sorted the language coding. I didn't see any equivalent for tz
Brian Postlethwaite (Aug 27 2019 at 23:18):
Check the usage and extensions heading. Lots of links to software handling it.
https://en.m.wikipedia.org/wiki/Tz_database
Eric Haas (Aug 28 2019 at 16:36):
What I had imagined was the three letter symbols like EDT, PDT but when I look at the Python Tz module:
Eric Haas (Aug 28 2019 at 16:38):
I don't see them but instead US/Central etc. Are they there in your favorite language module?
Eric Haas (Aug 28 2019 at 16:43):
based on this: https://www.timeanddate.com/time/zones/
the three letter codes are not unique :-(
Jenni Syed (Aug 28 2019 at 16:45):
Technically, all 3 letter TZ abbreviations are supposed to be bad practice in the coding world because they're ambiguous
Jenni Syed (Aug 28 2019 at 16:46):
The preferred format is the long format - many libraries have methods that allow you to build displays with either, but parsing a 3 letter display can lead to unexpected consequences, depending on how your particular date library has defined it's functionality
Eric Haas (Aug 28 2019 at 16:46):
of course nothing is simple
Jenni Syed (Aug 28 2019 at 16:46):
EG: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/TimeZone.html#SHORT
Jenni Syed (Aug 28 2019 at 16:47):
I find that things we think are simple in real life are generally some of the most complex things in computers :)
Jenni Syed (Aug 28 2019 at 16:47):
EG: "Strings"/writing, date/time, math (decimals and fractions)
Jenni Syed (Aug 28 2019 at 16:48):
Essentially: did you learn this in kindergarten? It's really hard for a computer ;)
Eric Haas (Aug 28 2019 at 18:00):
so can we at least come up with a list of common timezones that include DST? I'm digging into the Python library...
Eric Haas (Aug 29 2019 at 03:08):
here is what I came up with for "Common Timezones" : https://github.com/Healthedata1/MyNotebooks/blob/master/TZ/Untitled.ipynb
Eric Haas (Aug 29 2019 at 15:19):
I found this http://hl7.org/fhir/ValueSet/timezones btw
Grahame Grieve (Aug 29 2019 at 21:01):
awesome. Just needs us to figure out what the code system is for it to have any meaning. At least it's not used
Bert Roos (Mar 29 2021 at 10:18):
This conversation lead to https://jira.hl7.org/browse/FHIR-23819, with a resolution that I find helpful. Given how long ago that resolution was defined, I wonder whether the resolution is accepted and will become part of the standard. Can we count on that? In other words, can we conclude that "America/Los_Angeles" is a valid time zone value?
Lloyd McKenzie (Mar 29 2021 at 14:46):
It's approved. Hopefully it'll make it into R5.
Bert Roos (Mar 29 2021 at 15:31):
Thanks!
Richard Townley-O'Neill (Mar 30 2021 at 00:37):
HL7 AU is using the following for time zones.
In HealthcareService we have an au-timezone extension on availableTime that uses an au-timezone value set with codes from https://www.iana.org/time-zones
Theo Stolker (May 07 2021 at 15:18):
For R4, the value set "http://hl7.org/fhir/ValueSet/timezones|4.0.1" can not be expanded, error displayed is: This value set could not be expanded by the publication tooling: Error from server: Unable to provide support for code system https://www.iana.org/time-zones
Can anyone recommend how to get a computable value set with all IANA Timezone codes?
I also need it for an STU3 project.
Michael Lawley (May 09 2021 at 04:39):
I downloaded the latest datafile (2021-01-24), imported into Snapper (https://ontoserver.csiro.au/snapper) and uploaded a draft here http://r4.ontoserver.csiro.au/fhir/CodeSystem/087db775-4227-435a-aefa-648485ad1dea
Theo Stolker (May 10 2021 at 09:25):
Thanks, Michael, that is awesome!! This is a great help!
David Simons (May 17 2021 at 18:16):
Ah - I may have to ask here - instead of https://chat.fhir.org/#narrow/stream/179166-implementers/topic/timezone.20expansion.20error :)
Can the codeSystem https://www.iana.org/time-zones be included on http://tx.fhir.org/ ?
(for STU3 and R4, please, @Grahame Grieve )
Or should IANA package and put this CodeSystem on registry.fhir.org ?
Our root question is - how to feed this CodeSystem into the HL7 Validator - when using it in our profiles....
Current gap-filler is to create an NPM package folder locally, from the https://www.iana.org/time-zones files, and include that as a folder dependency in HL7 Validator
Grahame Grieve (May 17 2021 at 19:43):
it'll be supported shortly - some time this week
David Simons (May 28 2021 at 14:32):
Thank you @Grahame Grieve - is http://tx.fhir.org/ down for this upgrade? ;)
Grahame Grieve (May 28 2021 at 15:41):
fixed.
Last updated: Apr 12 2022 at 19:14 UTC
