Does SensorReading always need a timeStamp ?

[riju]

@timvolodine asked : concrete sensors readings would derive from SensorReading. However do we always need a timeStamp? looks like can be potentially overhead for very hi-frequency
sensors. Maybe it should be nullable or not there at all ?

[tobie]

timestamps are the only way to compute both latency and frequency, so it seems like they're super useful.

What's the overhead of providing those? I imagine they're provided by the underlying platforms anyway, no?

[tobie]

Also, without timestamps, how would we know the freshness of the sensor reading?

[riju]

Atleast on Android side, SensorEvent provides timestamps.

public void onSensorChanged(SensorEvent event) {
     if (event.sensor.getType() == Sensor.TYPE_LIGHT) {
          mLastUpdate.illuminance = event.values[0];
          mLastUpdate.timestamp = event.timestamp;
     }
} 

[tobie]

What does that timestamp correspond to? It's unclear from the docs.

[riju]

The time in nanosecond at which the event happened
Source : SensorEvent

[tobie]

So it's the time at which the event object is constructed, not the time of the reading.

[riju]

Yes there is some confusion in the docs, maybe I should use the timestamps this way

long timeInMillis = System.currentTimeMillis()
                             + ((event.timestamp 
                             -  SystemClock.elapsedRealtimeNanos())/1000000L);

[tobie]

Well, what we want is a monotonic clock here, so DOMHighResTimeStamp is the way to go. I don't know if the above gives you that.

[tobie]

So there seems to be confusion as to what base this timestamp is from, and whether it's the timestamp at which the event is dispatched or at which the sensor data is obtained.

[mwichmann]

This is an interesting problem. There are all kinds of sensors, and thus a number of different reporting styles. In some cases it's important to relate the event to a real time - we want to know that this reading was taken at 8:02 AM locally, which means we want to know the timezone/DST situation as well. In some other cases the interesting data is the relative time to other captures - here we don't want tz/dst, and we don't want to be affected by any possible time changes on the device. Think of these as Realtime Clock vs. Monotonic Clock. And I can imagine in some cases, we may not care at all about the time - that's the original subject of this issue. In general, the situation is more determined by the sensor in question than the application talking to it. Can there be a way to express the time in a flexible way such that the sensor can choose any of these three as their preferred reporting style?

[tobie]

This spec exclusively focuses on local MEMS sensors for now, so we're looking at monotonic time stamps only as I don't think there are use cases for epoch-based timestamps which can't be easily solved with an in document conversion. Of course, once we'll move these to service workers, considerations will be different, but that's not the only thing that'll need to be reconsidered.

I think the key questions here are:

• are there perf reasons to avoid timestamps?
• what do the timestamps in the underlying platform actually measure?
• do those underlying timestamps actually help us meet our use cases?

[timvolodine]

We should probably stick to using the timestamps provided by the platform (?)
not really sure about the use-cases, but may be actually useful for measuring how "stale" a particular data is (as was already mentioned by @tobie I think)

Looks like on Android and Windows there are timestamps provided by the platform (although the exact semantics may be different). However I am curious as to what will happen if a platform is unable (or unwilling ;)) to provide timestamps.. or does this never happen?

[tobie]

We should probably stick to using the timestamps provided by the platform (?)

Agreed (though we'll obviously have to convert them to whatever baseline we're using).

not really sure about the use-cases, but may be actually useful for measuring how "stale" a particular data is (as was already mentioned by tobie@ I think)

Yes. Measuring latency (granted the timestamp is that of the sensor reading, and not the Java event) and frequency also come to mind.

Looks like on Android and Windows there are timestamps provided by the platform (although the exact semantics may be different). However I am curious as to what will happen if a platform is unable (or unwilling ;)) to provide timestamps.

Well, in that case, I guess we'd just use the equivalent of calling performance.now().

or does this never happen?

I think all underlying platforms have at least a timestamp for when the reading is communicated to UA (or can generate one pretty easily).

[anssiko]

F2F agreement, we'll do need a timestamp for SensorReadings.