Time Zone Issues

[bhuang]

So, it was wishful thinking that changing the time zone in myair profile would change the time axis of Oscar. It has not worked last night. Still the same problem. The starting time is Eastern and the ending time looks like Pacific. My oximetry O2Ring works. So, last thing to try. Will change the clock in Airsense 10 and see what happens tonight.

[Goofproof]

Well, I just told friends how great Oscar is. Then in one day, I found that when the time zone changed in the PC, the old data time mark changed. That's not good.

Demand your money back!

From Bill Gates!

[bhuang]

So, I changed the clock of Airsense 10 to Pacific time last night. Now all has gone wild.
1. myair tells me that I did not use the CPAP last night. So, it is Resmed's product engineering problem.
2. Oscar again shows the data starting at 00:40 and ended this morning at 04:40, but actually I used the CPAP starting at 22:15 and ending at 05:58 this morning, so Oscar cuts 1 hr 20 min from starting and 1 hr 20 min from ending.

So, In conclusion, Resmed does have a time zone issue by itself and Oscar has trouble with Resmed's time zone confusion.

[khauser]

So, I changed the clock of Airsense 10 to Pacific time last night. Now all has gone wild.
1. myair tells me that I did not use the CPAP last night. So, it is Resmed's product engineering problem.
2. Oscar again shows the data starting at 00:40 and ended this morning at 04:40, but actually I used the CPAP starting at 22:15 and ending at 05:58 this morning, so Oscar cuts 1 hr 20 min from starting and 1 hr 20 min from ending.

So, In conclusion, Resmed does have a time zone issue by itself and Oscar has trouble with Resmed's time zone confusion.

The clinician's manual warns that changing the time can cause confusion. Give it a day or two...

The xPAP has zero knowledge of timezone. What you did is changed the time it records at so it COINCIDES with your time zone.

I do not believe OSCAR does anything around timezone. It reports the recorded timing, period.

I can't speak to myair, I don't use it.

I am a software engiineer, and timezones are actually massively confusing to the issue of saving and displaying times. I imagine that by providing a timezone to myair you are simply causing it to assume the times on the machine are in that timezone. There's no benefit I can imagine to that...

[Goofproof]

So, I changed the clock of Airsense 10 to Pacific time last night. Now all has gone wild.
1. myair tells me that I did not use the CPAP last night. So, it is Resmed's product engineering problem.
2. Oscar again shows the data starting at 00:40 and ended this morning at 04:40, but actually I used the CPAP starting at 22:15 and ending at 05:58 this morning, so Oscar cuts 1 hr 20 min from starting and 1 hr 20 min from ending.

So, In conclusion, Resmed does have a time zone issue by itself and Oscar has trouble with Resmed's time zone confusion.

When do you find time to sleep if you are flying around in circles, playing with your XPAP and Computer like a balloon let loose without tying a knot in it I guess you get one big puff of air at least. How is the new XPAP data program you are writing coming, I waiting to see how good it is, with everything, even things it's not designed to do. Jim

[bhuang]

Last night, I revert everything back to defaults
1. the timezone in myair back to Eastern.
2. the Airsense back to Eastern time.
Most importantly maybe
3. didn't pull the SD card out until data is sync to myair.
4. PC timezone also switch back to Eastern.

Oscar does show last night time scale in Pacific time and all previous data in Eastern time. This is exactly what I wanted it to be. As long as it works that way I am not fooling around with the timezone in my PC. Thanks for all inputs.

[ChicagoGranny]

3. didn't pull the SD card out until data is sync to myair.

myAir has nothing to do with the SD card. The machine can be used without an SD card and still transmit data to myAir.

I can't say for sure, but it seems like after the machine is turned off in the morning, it takes a few hours before it will transmit the data to the cell tower. You can speed this up by clicking on myAir in the machine display Report menu. The data will transmit immediately. However, the ResMed server will still take some time to update its files.

About that SD card, after turning the machine off in the morning, you might want to wait a minute to pull the card. This is to make sure all the data from the machine has downloaded to the card.

[bhuang]

Thanks,
Saga continues, did the same thing this morning to make sure I got the data right. However, the time axis is offset again. It is not exactly 3 hours.
Starting time 1:13 this morning, instead of 22:35 last night
ending time 9:03 this morning, instead of 6:38 this moring

Definitely need to try ResScan these days.

[Goofproof]

It's not a Saga, it's a monologue, one that only seem you seem care about.

[BlueDragon]

Maybe an explanation of how OSCAR handles times will help.

Your ResMed CPAP machine has a clock, and you can set the date and time from the clinician's menu. Nothing else changes the clock. The machine doesn't know anything about DST or timezones, nor does it synchronize itself with anything. It's just a very simple clock that keeps running as you set it.

The clock may "drift" slightly. I just reset my wife's Autoset clock after two years and it had drifted several minutes (that's assuming I had set it accurately in the first place -- which I can't know for sure). Unless you are matching the data to another source -- such as a recording oximeter -- and importing that into OSCAR, a slight drift makes no practical difference and CPAP users are unlikely ever to notice it.

Now, what does OSCAR do?

When OSCAR imports the data, it assumes the clock is using the same time settings as the computer. It assumes that if the data says 11 pm that means the same 11 pm that the computer understands to be 11 pm. To put it another way, OSCAR assumes that the CPAP clock and the computer's clock are set to the same timezone. It then converts all timestamps it is importing to UTC/GMT and stores them in its database. So the database contains times in UTC/GMT.

When OSCAR displays the data, it converts the UTC/GMT timestamps to local time, as defined by the computer's time settings. If the computer's time zone is the same as when the data was recorded, then the times you will see are the same as they were when imported. If your computer is set to a different time zone, the results shift, as you have noticed.

One possible source of confusion: if you change the computer's timezone while OSCAR is running, some, but not all, times will reflect the change. If you change the computer's time zone, you need to restart OSCAR to have the change reflected properly in all places that OSCAR shows the time.

Hope this helps understand what is happening.

[bhuang]

Hello BlueDragon,
Thanks much for the explanation. I will install ResScan and do some testing next week. I just want to make the team aware of the issues that I encounter. Hopefully, the team will look into it. If it is only my problem, maybe that's why the market is not there for such a program. In any case, I just like to emphasize that
1. Once the time scale is registered with a set of data for a night. It is historical. If one changed the time zone in the computer, the time axis of the apnea events should not change. It is historical. The events occurred at certain times.
2. The newly imported data should line up with the CPAP time. Now they are not when I sleep in another time zone.

I am not joking, so I don't respond to those who think that I am asking too much for something that is free. I was just surprised by how good the software was before I sleep in another time zone.

[BlueDragon]

I am a software engiineer, and timezones are actually massively confusing to the issue of saving and displaying times.

I totally agree with khauser about saving and displaying times. That's what we are seeing here.

The issue you are seeing can be argued either way. The emphasis in OSCAR is to record the data accurately. Arguably, converting time to GMT/UTC creates maximum accuracy. Yes, there is a time shift when you look at data in OSCAR in a different time zone than when it was imported. But the numbers you are seeing are still "accurate." For example, if you go to sleep at 9 pm EST and look at the data later in PST, it says you went to bed at 6 pm. But that's 6 pm PST, which is the same as 9 PM EST, so reporting that as 9 pm instead would be "false." If you want to see the data as you would have seen it in EST, just change your computer's timezone to EST and all will be as you saw it originally.

If you are arguing that OSCAR should always display the times as they were originally displayed and preserve the original display when you move to a different timezone, I understand that point of view. That's more database complexity and I can envision edge cases that would make it difficult for that approach ever to be totally satisfactory in all situations.

It doesn't matter which way OSCAR handles times, there are likely to be some wrinkles with time zone changes.

[ChicagoGranny]

I am not joking

Are you interested in optimal CPAP therapy or just fiddling around with data?

[Goofproof]

I am not joking

Are you interested in optimal CPAP therapy or just fiddling around with data?

He's not got any toys he can master to play with, so he comes here to play with us. Don't Play with Trolls. Jim

[chunkyfrog]

I am not joking

Are you interested in optimal CPAP therapy or just fiddling around with data?

He's not got any toys he can master to play with, so he comes here to play with us. Don't Play with Trolls. Jim

I do not always agree with you; but today I'll make an exception.