Confusion: timestamps in `timestamps.json` seems all within 1 second after `1970-01-01 00:00:00`

[OuYaozhong]

Hi ,there, @MarioBijelic

In Brief

The way to process the timestamps in tools/DatasetViewer/timestamps.json make me confuse.

All the time stamps are within 1 sec after the start point 1970-01-01 00:00:00, since they are all less than 10 digits (i.e., <= 9 digits)

The analysis is based on the interpretation method cited by convert_timestamp (tools/DatasetViewer/utils_DataViewer.py#L138),

where tells that the last 9-bit digits of the timestamps represents $10^{-9}$ second and the rest most-significant digits represents the second.

All-less-than-10-bit-digit timestamps in timestamps.json make the time shown are all same at the 1970-01-01 00:00:00 (refer to the picture at the last).

🌟Question: What happened ? Any mistake here or I missing something ?

---

Detail Description

I found that there is an tools/DatasetViewer/timestamps.json file, reflecting the real captured time of the data.

I also found some code in tools/DatasetViewer/DataViewer_V2.py, telling that how the author processing this timestamps file.

In tools/DatasetViewer/DataViewer_V2.py line 279, it has following codes:

self.stereo_timestamp = self.get_timestamp_from_data_name(topic='rgb')
if self.stereo_timestamp is not None:
    date = convert_timestamp(self.stereo_timestamp)
    self.timeRGBEdit.setText('{}'.format(date))
else:
    self.timeRGBEdit.setText('No timestamp found!')

And the self.get_timestamp_from_data_name is defined as below in tools/DatasetViewer/DataViewer_V2.py line 666:

def get_timestamp_from_data_name(self, topic):
    recording = self.recordings[self.current_index]

    # get matching file name from AdverseWeather data
    matching_label_topic = self.timedelays.get(topic)
    old_data_name = matching_label_topic.get(recording.split('.png')[0], 'NoFrame')
    if old_data_name != 'NoFrame':
        old_data_name = os.path.splitext(old_data_name)[0]
        old_data_name = old_data_name.split('_')[1]
        stereo_timestamp = int(old_data_name)
        return stereo_timestamp

    else:
        return None

From above codes, we can see that the timestamps is indexed by the filename of the data, the corresponding timestamp value is saved in the json file timestamps.json in a dictionary style.

In the timestamps.json, the content is organized as following structure:

{
    "modal": {
        "filename": "{old_timestamp}_{new_timestamp}"
    }
}

What above codes do is using file name of the data to index the "{old_timestamp}_{new_timestamp}" string pair.
Then, the {new_timestamp} is the corresponding true time stamp at the time when data is captured.
And the {old_timestamp} is the same as the one at the end of the file name string.

Here are some examples.

"2018-02-03_21-36-01_00100": "00100_-9235816",
"2018-02-03_21-36-01_00200": "00200_-40654056",
"2018-02-03_21-36-01_00300": "00300_-21753718",

Then, author try to convert the time stamp into the real date format, by the code:

date = convert_timestamp(self.stereo_timestamp)

Above self.stereo_timestamp is the same as {new_timestamp}.

The code about the convert_timestamp is here:

def convert_timestamp(timestamp):
    dt = datetime.fromtimestamp(timestamp // 1000000000)
    s = dt.strftime('%Y-%m-%d %H:%M:%S')
    s += '.' + str(int(timestamp % 1000000000)).zfill(9)
    return s

From the code above, it seems that the timestamp should be format as
| n-bit seconds | + | 9-bit $10^{-9}$ second |
The seconds are count from 1970-01-01 00:00:00

So, the unit of the {new_timestamp} is $10^{-9}$ second, then, timestamp = 1,000,000,000 means 1 sec after 1970-01-01 00:00:00, (i.e., 1970-01-01 00:00:01).

However, most of {new_timestamp} in timestamps.json are less than 1000, and even lots of are negative, meaning that the data is captured before year of 1970.

Meanwhile, there are some data are large enough.

There are only 19 {new_timestamp} have 9 digits, meaning that they represent least 0.1 sec, and no {new_timestamp} has >=10 digits, meaning that all {new_timestamp} are < 1 sec after 1970-01-01 00:00:00.

The usage of datetime shown below:

Python 3.12.9 | packaged by Anaconda, Inc. | (main, Feb  6 2025, 18:56:27) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import datetime
>>> import time
>>> datetime.fromtimestamp(time.time())
datetime.datetime(2025, 5, 22, 15, 28, 48, 284906)
>>> datetime.fromtimestamp(0)
datetime.datetime(1970, 1, 1, 1, 0)
>>> datetime.fromtimestamp(1)
datetime.datetime(1970, 1, 1, 1, 0, 1)

The result is that, in the UI of tools/DatasetViewer/DataViewer_V2.py, it always shows that the data is captured in 1970-01-01 00:00:00 (various based on the timezone you set)

It seems strange and impossible

🌟Could you explain what happened ?

Thanks in advance.

Best Regards

[OuYaozhong]

@MarioBijelic

I found some clue showing that this problem has existed for a long time, and may be not the fault for my modification of your code.

The clue is that in an issue open in year 2020, #18, the author of that issue has shown several screenshots of the running UI results of tools/DatasetViewer/DataViewer_V2.py. The timestamps shown in screenshots in above issue is also 1970-01-01 01:00:00 (in fact is 1970-01-01 00:00:00, vary based on the timezone)

I copy the screenshots in #18 below as a backup.

(above three screenshots is copied from #18 )

[OuYaozhong]

@MarioBijelic

I suddenly found that there is also a timestamp in each .json file inside weather_station dataset split.

I each .json file in the weather_station, it has a key name header, for example weather_station/2019-05-02_21-29-28_00690.json

{
    "key1": ...,
    "key2": ...,
    ....
    "header": {
        "stamp": {
            "secs": 1556825441, 
            "nsecs": 544384956
        }, 
        "frame_id": "weather_station", 
        "seq": 83188
    },
    ....
}

In the key header, there is a sub-key name stamp, I guess this refer to timestamp.

And the sub-key stamp also have two sub-sub-keys, named secs and nsecs, respectively. I don't know the difference between them.

But I have check the secs, it seems that the value of header/stamp/secs is very similar to the time in file name.

Python 3.12.9 | packaged by Anaconda, Inc. | (main, Feb  6 2025, 18:56:27) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from datetime import datetime
>>> datetime.fromtimestamp(0)
datetime.datetime(1970, 1, 1, 1, 0)
>>> datetime.fromtimestamp(1556825441)
datetime.datetime(2019, 5, 2, 20, 30, 41)

If use the header/stamp/secs in weather_station/2019-05-02_21-29-28_00690.json as timestamp, and then feed into the python package datetime to transfer the timestamp into the human-readable format, the result is very close to the one wrote in the file name 2019-05-02_21-29-28_00690.

Actually, it still have several minutes shift between them.

---

One more thing, the weather_station seems not intact. Inside the weather_station, there are only 10280 .json files, while the other modal all have 12997 files.

(base) user@hostname:~/Downloads/STF$ rm -r weather_station
(base) user@ hostname:~/Downloads/STF$ md5sum weather_station.zip 
32ec7b2d215d8579fc054e8bd45c7b1e  weather_station.zip
(base) user@ hostname:~/Downloads/STF$ unzip -q weather_station.zip 
(base) user@ hostname:~/Downloads/STF$ cd weather_station/
(base) user@ hostname:~/Downloads/STF/weather_station$ ls | wc -l
10280

---

So, waiting for the correct data or way to get the time stamp, and the intact weather_station split.

Thanks !

[MarioBijelic]

Hi @OuYaozhong,

thank you for the detailed bug report!
The amount of weather station labels is intact, this published weather station was added for later capture campaigns only and previous used weather stations did not report accurate measurements due to the vehicles dissipated heat.
We did not officially upload the image timestamps. We have only published the delta between the individual sensor messages, such that ego motion corrections can be applied.
Please let me know, why do you need the full timestamp?

Best regards,
Mario

[OuYaozhong]

Hi, @MarioBijelic

It is no need to get the real captured time (or said timestamp), but I want to know about the real time interval between two adjacent frames, and know which data are adjacent.

What you said is exactly what I guess, the timestamp may be the time difference between the sensors in the same frame, and does not mean the time when they are accurately captured.

Because I try to use the data in a sequence style.

The precise time interval between two adjacent frames can help me to locate the position between two captured time, using in SLAM under adverse weather.

So, I do not need the precise captured time, but a timestamp to tell how to gather the sequences (for example, gather the data whose time difference is < 10 seconds), and the time interval cooperated with the vehicle speed and steering angle in filtered_relevant_can_data can help me calculate the related position between two adjacent frame.

Not sure if I described clearly what I want to do, and why I need the timestamp ?

It is welcome and No hesitation to contact if any problem.

Thanks

Best Regards,

[MarioBijelic]

Hi @OuYaozhong,

the frames are individually captured mostly with 1 second> time difference to get as much as possible diversity. Though I also have the corresponding 10Hz sequences available used in previous works for visualisation. Let me know if this would help your work and shoot me a message via mail, then we can figure out how to collaborate.

Best regards,
Mario