Under what circumstances can someone ask a question that can mean one thing in one part of the country and yet something entirely different in another? When what they are talking about is time. Just ask your colleague from the left or right coast what time it is, and you'll see they come up with a different answer than you do.
Here's the challenge: A FHIR Server hosts a number of resources, and each of them have an associated timestamp in Resource.meta.lastUpdated. So what should you get when you ask for resources that have been updated recently? Well, frankly it depends upon how you ask.
If you give a date only with no time zone, then the answer you SHOULD get back is the based on the date you supply, as interpreted in the context of the resource that has the timestamp.
Consider: Resource A has timestamp given in terms of Eastern Standard Time. Resource B has the same timestamp, but using Pacific Standard Time. Resource C has the same timestamp, but using India Standard Time. If C was updated today, is it also true that A and B were? Not for certain, at least according to my thinking.
The answer is, it depends. First of all, it cannot matter to the server where you are if you don't tell it, so if you give a query based on a date (and thus without a timestamp), it will have to use what it knows, which is whatever timezone it uses for local reference. Some servers may set local reference time to UTC, others while most would use the local time zone, yet others may have standardized on the local time at wherever headquarters happens to be. Even so, the variations don't matter, what matters is if you say nothing, the server has to interpret the value. If you do happen to tell the server where you are (e.g., by giving a timestamp with a timezone -- and thus hours and minutes at the very least), then it should interpret time according to what you told it. So far, so good.
Next up. But what about what the resource say? Why does this matter you might ask. Well, the server and the resource may not agree on what should be in the timezone of a timestamp. In fact, if your server is just a raw FHIR repository of data, with some applications storing data, and others reading it, then it is the application which decides the timezone associated with the timestamp. So, if you are with me so far:
Resource A was created a T in EST, B at T - 3 hours measured in PST, and C at T + 10:30 hours. A time span measuring 13 and 1/2 hours. More than half the time of the day, the crossover from one day to the next will be between resource B and Resource C's location. And Resource A will be on one side or the other (it can get worse: If you have your resources on Baker Island, New Zealand and the Line Islands, where for a couple of hours, each could be stamped with a different day). So NOW what?
If comparing by date alone, the resource date could actually be the one to rule. If comparing my day to the resource's day, where we disagree on what the time zone is, how is a body (or a server) to compare the two. We could agree to use the servers time as the point of arbitrage, and the problem would be solved.
Or would it? How do you commit baseline test results for your server codes unit tests when you have developers in all three zones running them on a local server?
**** if I know anything other than a completely arbitrary answer. If you have a better one, I'd love to hear it.
Keith
Here's the challenge: A FHIR Server hosts a number of resources, and each of them have an associated timestamp in Resource.meta.lastUpdated. So what should you get when you ask for resources that have been updated recently? Well, frankly it depends upon how you ask.
If you give a date only with no time zone, then the answer you SHOULD get back is the based on the date you supply, as interpreted in the context of the resource that has the timestamp.
Consider: Resource A has timestamp given in terms of Eastern Standard Time. Resource B has the same timestamp, but using Pacific Standard Time. Resource C has the same timestamp, but using India Standard Time. If C was updated today, is it also true that A and B were? Not for certain, at least according to my thinking.
The answer is, it depends. First of all, it cannot matter to the server where you are if you don't tell it, so if you give a query based on a date (and thus without a timestamp), it will have to use what it knows, which is whatever timezone it uses for local reference. Some servers may set local reference time to UTC, others while most would use the local time zone, yet others may have standardized on the local time at wherever headquarters happens to be. Even so, the variations don't matter, what matters is if you say nothing, the server has to interpret the value. If you do happen to tell the server where you are (e.g., by giving a timestamp with a timezone -- and thus hours and minutes at the very least), then it should interpret time according to what you told it. So far, so good.
Next up. But what about what the resource say? Why does this matter you might ask. Well, the server and the resource may not agree on what should be in the timezone of a timestamp. In fact, if your server is just a raw FHIR repository of data, with some applications storing data, and others reading it, then it is the application which decides the timezone associated with the timestamp. So, if you are with me so far:
Resource A was created a T in EST, B at T - 3 hours measured in PST, and C at T + 10:30 hours. A time span measuring 13 and 1/2 hours. More than half the time of the day, the crossover from one day to the next will be between resource B and Resource C's location. And Resource A will be on one side or the other (it can get worse: If you have your resources on Baker Island, New Zealand and the Line Islands, where for a couple of hours, each could be stamped with a different day). So NOW what?
If comparing by date alone, the resource date could actually be the one to rule. If comparing my day to the resource's day, where we disagree on what the time zone is, how is a body (or a server) to compare the two. We could agree to use the servers time as the point of arbitrage, and the problem would be solved.
Or would it? How do you commit baseline test results for your server codes unit tests when you have developers in all three zones running them on a local server?
**** if I know anything other than a completely arbitrary answer. If you have a better one, I'd love to hear it.
Keith
Have all of your developers set their test/local machines to the UTC time zone.
ReplyDelete