tag:blogger.com,1999:blog-733074358901582680.post7546977636557433422..comments2024-03-13T07:28:50.206-04:00Comments on Healthcare Standards: UTC in HL7 Version 3Keith W. Boonehttp://www.blogger.com/profile/16883038460949909300noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-733074358901582680.post-33532616621571643172010-01-05T14:43:06.969-05:002010-01-05T14:43:06.969-05:00Note that RFC 2822 (the email standard) uses timez...Note that RFC 2822 (the email standard) uses timezone offset -0000 to indicate local time.<br /><br />DICOM requires a 4 digit timezone offset, and forbids -0000.Harry Solomonhttps://www.blogger.com/profile/01135539798417593756noreply@blogger.comtag:blogger.com,1999:blog-733074358901582680.post-3350772498600599672009-12-12T20:13:03.471-05:002009-12-12T20:13:03.471-05:00The XML ITS says: In short, the syntax is "Y...The XML ITS says: <i>In short, the syntax is "YYYYMMDDHHMMSS.UUUU[+|-ZZzz]" where digits can be omitted from the right side to express less precision.</i><br /><br />It doesn't specify where digits can be omitted from (the time or time zone). ISO 8601 allows them to be omitted from either. Datatypes-base.xsd that ships with CDA allows for 1 to 4 digits of time zone to be specified.<br /><br />Best practice would be to use all four, but it appears to me that the standard allows for fewer.Keith W. Boonehttps://www.blogger.com/profile/16883038460949909300noreply@blogger.comtag:blogger.com,1999:blog-733074358901582680.post-85773185750181157362009-12-12T09:30:38.254-05:002009-12-12T09:30:38.254-05:00AFAIK (in HL7 datatypes R1) Timezones always have ...AFAIK (in HL7 datatypes R1) Timezones always have to be specified using 4 digits.Unknownhttps://www.blogger.com/profile/12894756432231557042noreply@blogger.comtag:blogger.com,1999:blog-733074358901582680.post-37290289218207636172009-12-11T17:42:10.308-05:002009-12-11T17:42:10.308-05:00Keith,
I like your blog article -- succint and co...Keith,<br /><br />I like your blog article -- succint and correct as usual! But there are still a few holes ...<br /><br /><br />CASE 1: NTP time (where local timezone is unknown) -- maybe we should use the "Z" suffix for that, implying a globally correct NTP timestamp referenced to UTC but where the local time zone is unknown.<br /><br />CASE 2: Time and timezone are both known, and you are in London, in which case you would use +00 or +0000.<br /><br />We need to unambiguously encode the two cases above.<br /><br />Another thing that is bugging me is why leap seconds are prohibited in W3C Schema (where you can have a 60th second in a minute, rather than the usual 0-59 seconds in a minute). W3C Schema does not allow a 60th second, whereas 8601 and NTP both support a 60th second in the minute when a leap-second is inserted. In other words, W3C Schema is incapable of representing these points in time that actually do exist in a purely isochronous timeline such as atomic clock time (e.g. TAI, GPS, etc.). [Maybe this could be fixed in W3C Schema 1.1]<br /><br />Best regards,<br /><br />Paul Schluter<br />GE HealthcareUnknownhttps://www.blogger.com/profile/15458667704656135588noreply@blogger.com