The provided ros time parameter is changed to ros::Time instead of WallTime and the timeToStr() function changed to actually use the provided time stamp (it was a Windows compatibility desire that resulted in that oddifty, and toBoost() didn't yet exist?) so that a bag recorded from other recorded messages with a recorded clock has a old date that is close to the content messages stamps rather than a current date. For example messages from a bag are played back with --clock and reprocessed and new messages generated, those all have the old timestamps and running rosbag info on the bag shows all the messages to be as if from the earlier time, and with this change the bag now has an appropriately old date string in the name.
An alternate strategy that ignores the ros time could be to use the timestamp of the first received message, but probably it isn't convenient to get that, the file has already been created.
There will be bags with odd 1970-01-01... names in the case of recording from a simulation that initializes time at 0 (gazebo does this)- users may be used to the bag have the meaningful timestamp of wall time when the simulation happened, but all the timestamps within the bag are incorrectly in 1970 (but because everyone is used to that it's a way to quickly recognize sim data). Ideally a new convention would be if the simulation needs to appear to have taken place today then it should be configured to start counting from the current time instead Unix epoch 0, and some other flag or convention is used to show clearly data came from a simulated source... but maybe the more expedient answer here is to make the WallTime get used optionally?
The provided ros time parameter is changed to
ros::Timeinstead ofWallTimeand thetimeToStr()function changed to actually use the provided time stamp (it was a Windows compatibility desire that resulted in that oddifty, andtoBoost()didn't yet exist?) so that a bag recorded from other recorded messages with a recorded clock has a old date that is close to the content messages stamps rather than a current date. For example messages from a bag are played back with --clock and reprocessed and new messages generated, those all have the old timestamps and running rosbag info on the bag shows all the messages to be as if from the earlier time, and with this change the bag now has an appropriately old date string in the name.An alternate strategy that ignores the ros time could be to use the timestamp of the first received message, but probably it isn't convenient to get that, the file has already been created.
There will be bags with odd
1970-01-01...names in the case of recording from a simulation that initializes time at 0 (gazebo does this)- users may be used to the bag have the meaningful timestamp of wall time when the simulation happened, but all the timestamps within the bag are incorrectly in 1970 (but because everyone is used to that it's a way to quickly recognize sim data). Ideally a new convention would be if the simulation needs to appear to have taken place today then it should be configured to start counting from the current time instead Unix epoch0, and some other flag or convention is used to show clearly data came from a simulated source... but maybe the more expedient answer here is to make the WallTime get used optionally?