Comments (5)
On first pass, not really able to reproduce this how I thought I would. I'll have to keep digging.
https://github.com/gitpushdashf/issue27
$ python3 issue.py | grep -- '[0-9]*T' | grep start | tail -n 1
"start": "2020-07-24T08:07:57-06:00",
$ cat 25dc5040-5875-8486-a49c-ed4789b7c88c.json | grep -- '[0-9]*T' | grep start | tail -n 1
"start": "2020-07-24T08:07:57-06:00",
$ cat 25dc5040-5875-8486-a49c-ed4789b7c88c.json | grep -- '[0-9]*T' | grep start > orig-starts
$ python3 issue.py | grep -- '[0-9]*T' | grep start > new-starts
$ diff -Naur new-starts orig-starts
$
from fhir.
I'm also using freezegun, so maybe there's some compatibility quirk between the two.
from fhir.
Hey @gitpushdashf!
First off, thank you so much for adding the json_format stuff. It's just been fantastic to work with.
Thank you, and we're glad to hear it! :)
We are trying to normalize to UTC (or rather, treat all dates as UTC). At least for now, in this bit of code.
What we're seeing is that when converting from FHIR JSON to protobuf to FHIR JSON, 2016-03-03T10:10:57-07:00 ends up getting represented as 2016-03-04. I've tried forcing UTC timezone on my system and am still seeing that.
Hmm interesting - I'd like to see a dump between each phase of the "round trip". The issue you're describing is strange for a couple of reasons to me:
- The precision of the result (
2016-03-04
) is inDAY
while your initial FHIR JSON value is specified in a higher precision; not sure if this was intentional? - Given that your original timezone is 7hrs behind UTC, it's interesting that the resulting value would be basically be rolled-over into the next day..
What value of default_timezone
are you providing to json_format
when parsing? I'm wondering if maybe the Python libraries fail to pick up a timezone offset, and perhaps we should be failing more loudly?
from fhir.
I'm also using freezegun, so maybe there's some compatibility quirk between the two.
Oh interesting -- could you provide a gist of an example testcase using freezegun
?
from fhir.
Heh, I'm sorry to waste your time. It actually looks like json_format is working fine.
My initial discrepancies were with our protobuf LPRs, converted a while ago in Java. It seems that the time fields on those may have been thrown off, vs the original json.
With that test case I wasn't able to see a single difference between the source LPR from Synthea and the outputted one, after converting to protobuf and back. Seems pretty remarkable to me. Even timzeone notations were kept.
To add to the complication, my Synthea patient had two Colonoscopies back to back, one on the third and one on the fourth. I didn't notice the one on the fourth and thought it was just messing with me after finding there was some time discrepancy between the protobuf and json.
Anyway, I very much appreciate your reply. If we do indeed find some kind of time zone or time conversion issue, I'll write up some more involved repository that actually demonstrates it and will send it your way.
In the meanwhile, thank you for your time and I hope you have a wonderful weekend.
from fhir.
Related Issues (20)
- Patient Id is not accepting string expecting type object
- Consider tagging submodule "go"? HOT 2
- [Go] How to parse profile HOT 3
- Unmarshaller support for R5 versions HOT 3
- Canonical FHIR Resource Enum HOT 2
- go: module source tree too large HOT 1
- R5 support
- py/ subtree accidentally deleted? HOT 1
- Idiomatic way of dealing with unknown fields? [golang] HOT 3
- Export extensions to their own fields on analytics print? HOT 2
- No need to require backports.zoneinfo on Python 3.9+ HOT 2
- Python 3.10 + 3.11 support HOT 2
- Python: Upgrade to abseil-py v1.0.0
- Missing GoalAchievementStatus code system
- Go - Task_Output encoded REST message does not match FHIR Store model HOT 4
- FHIR 4.3.0 / R4B support
- protobuf 4.21 support HOT 1
- Building under Windows using MSVC HOT 1
- FR: Exposing a list of maven deps HOT 1
- Example for Generating Protos Using the scripts seems broken
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fhir.