pcl::HDLGrabber::toPointClouds: wrong timestamp format?

This is just something minor that I noticed while trying to figure out the timestamp semantics (Pull Request #684). Someone who has used the HDLGrabber might be able to comment on this better than I can.

The PCLHeader timestamp field is apparently supposed to represent microseconds since the UNIX Epoch. pcl::HDLGrabber::toPointClouds sets the timestamp as follows:

time_t  time_;
time(&time_);
time_t velodyneTime = (time_ & 0x00000000ffffffffl) << 32 | dataPacket->gpsTimestamp;
current_scan_xyz_->header.stamp = velodyneTime;

Whatever this produces, I strongly doubt it is a valid timestamp -- it uses the upper 32 bits of the 64-bit timestamp field to hold the seconds, and the lower 32 bits to hold the Velodyne scanner's gpsTimestamp. According to the Velodyne HDL-32E manual, this value "represents microseconds from the top of the hour to the first laser firing
in the packet." So, in any case, the timestamp calculation here appears grossly wrong.

I myself don't use Velodyne scanners at the moment, and I don't have the time to work on this myself. But someone else might be interested in fixing this.

Start at pcl::HDLGrabber::toPointClouds and inspect how dataPacket->gpsTimestamp is combined with the current time before assigning PCLHeader::stamp. Check the Velodyne HDL-32E timestamp semantics against PCL's expected units. Done means the resulting timestamp has a valid, documented representation and is covered by an appropriate regression test.