meas_date documentation inconsistency

[massich]

In mne.Info, meas_date is a list of two ints.

mne-python/mne/io/meas_info.py

Line 149 in ff8ebca

meas_date : list of int

however, based on _handle_meas_date, raw.info['meas_date'] can have other formats.

mne-python/mne/annotations.py

Lines 272 to 281 in ff8ebca

	def _handle_meas_date(meas_date):
	"""Convert meas_date to seconds."""
	if meas_date is None:
	meas_date = 0
	elif not np.isscalar(meas_date):
	if len(meas_date) > 1:
	meas_date = meas_date[0] + meas_date[1] / 1000000.
	else:
	meas_date = meas_date[0]
	return meas_date

(Also, I find _handle_meas_date naming confusing, plus I don't understand why is a free function. IMHO it should be raw object method. i.e: raw.get_meas_date_in_absolute_seconds but I don't have enough arguments to do a proper assessment)

[larsoner]

however, based on _handle_meas_date, raw.info['meas_date'] can have other formats.

I think after I/O round trip it is always 2 ints. We probably need to improve our raw readers to make it more consistent. We could add a test to _test_raw_reader to ensure each class did it correctly. Want to take a stab at it?

IMHO it should be raw object method

I guess you could make it an Info method (better than Raw because meas_date exists in Info, which can be in other objects) if you want. However I don't see too much to gain in this case, and it would complicate the git blame of the function/method, so I'm -0 on this.

[agramfort]

yes we need more consistency in the raw data readers. regarding the floating functions I prefer these when private as users don't get exposed to them with using tab completion. End users should not see these functions.

[massich]

@agramfort I'm not sure I fully follow your thought here.

[agramfort]

_handle_meas_date cannot be discovered with tab so easily. Whereas if I have a method in Annotations I just use tab in an instance of annotations and I start seeing a bunch of private functions I should not see. Clear?

[larsoner]

I think this is fixed