Format of timestamp in created_at field

[sccn]

Format of timestamp in created_at field

[cboulay]

I only found once place in liblsl where created_at gets set: here info_->created_at(lsl_clock())

So, just like the timestamps, it uses lsl_clock(), which is lsl_local_clock(), which is implemented here as follows:

LIBLSL_C_API double lsl_local_clock() {
	return std::chrono::nanoseconds(std::chrono::high_resolution_clock::now().time_since_epoch())
			   .count() /
		   1000000000.0;
}

I'll leave it to you to do your own research on std::chrono::high_resolution_clock::now().time_since_epoch(), but the short version is that on MacOS epoch is last reboot, and in Windows and Linux epoch is supposed to be Unix Epoch (1970-01-01).

[tstenner]

The lsl_clock timestamp format is an implementation detail, that corresponds to the Unix epoch in some cases and the computer start time (preferably without clock adjustments / jumps) in others. This is mostly a good thing, as the floating point precision drops the larger the timestamps get, but created_at should be a unix timestamp.

This should be fixed in liblsl. Would an additional created_at_uts field suffice?

[agricolab]

https://github.com/sccn/labstreaminglayer/wiki/Frequently-Asked-Questions

What clock does LSL use? / How do I relate LSL's local_clock() to my wall clock? LSL's local_clock() function measures the time since the local machine was started, in seconds.

Afaik, there is no field.

Maybe one can correlate the timestamp of the xdf-file with the timestamps in the footer?

[agricolab]

In pylsl though, local_clock returns the same timestamp as time.monotonic (tested in in windows and linux). Yet monotonic documentation says

Return the value (in fractional seconds) of a monotonic clock, i.e. a clock that cannot go backwards. The clock is not affected by system clock updates. The reference point of the returned value is undefined, so that only the difference between the results of consecutive calls is valid.

[cbrnr]

Alright, the FAQ confirms that LSL timestamps are seconds since the computer was started, but it doesn't talk about the created_at field in XDF files specifically so I wanted to make sure.

I don't think the creation date can be inferred from the footer timestamps either, because these have the same format. A new field would be certainly nice to have. Instead of adding a new field to a stream header, the XDF file header could also contain a Unix time stamp when the file was actually created (this requires a correct clock of course).

[agricolab]

Regarding created_at, i just wanted to note that apparently this is the time of creation of the outlet - not the info, from the senders side.

I am unsure whether the inlet is updating this ever, e.g. if the connection broke and a new StreamOutlet was created. Some quick testing seemed to show that it actually doesn't.

Would this not imply that hot-swapping could result in a corrupted created_at used by the inlet?

[agricolab]

What i usually do when i need unix timestamps, i just send them in a marker stream from the same device... Depending on the usecase at regular intervals or as event. This is at least save for reconnection/hotswapping.

[cbrnr]

Yes, it is the creation of the outlet in seconds since the computer running the outlet was started.

I don't want to question the format of the currently used timestamps at all. Instead, I think XDF should have a field containing the actual file creation date (which should equal the recording datetime). I think a new field is necessary for this, but I'm not sure if each stream header should have such a field or if a single datetime in the file header would be the better option. XDF bundles streams, but when I'm interested in the recording start time, I guess I'd take the earliest datetime of all streams.

[niteshbhatia008]

Hi,
I am a bit unclear about how the system time is used in timestamps. In my case, for example, the created_at time stamp is '89292.626145' which if I convert to date-time in Matlab corresponds to '21-Jun-0244 15:01:38' which is not correct.

[cbrnr]

Thanks @cboulay. So all timestamps mentioned in this thread seem to have been recorded on a Mac. It would be nice to know when a file was created though. I guess this is currently not possible?

[tstenner]

The epoch of std::chrono::high_resolution_clock isn't known and the offset between a real time clock at t0 is both unknown and might be different than the time offset at a later time. Putting in an absolute time might entice someone to just recalculate the timestamps as unix timestamps so I'd be hesitant to put it in the header.

Adding a field to the xdf file is a good idea, but that belongs in the LabRecorder repository.

[cboulay]

I think we can close this issue now. But @cbrnr , I agree with Tristan that this is a good idea to add in LabRecorder. Please open the issue there: https://github.com/labstreaminglayer/App-LabRecorder/issues