Allow microseconds in scans file datetimes

[tsalo]

This is related to nipy/heudiconv#447, nipy/heudiconv#451, and physiopy/phys2bids#219. Currently, the _scans.tsv file only allows acq_time with resolution down to the second. For the purposes of increased accuracy and to make it easier to synchronize scan data with simultaneously-acquired data from other modalities (e.g., physio data), it would be helpful if scans files' acq_time column allowed (but didn't require) microseconds as well. So acq_time could be 2009-06-15T13:45:30 or 2009-06-15T13:45:30.500000.

[nicholst]

Seems reasonable. I can't find an authoritative reference, but it seems that in Unix land fractional seconds (separated by a period) is preferred.

[sappelhoff]

as long as we stay within RFC3339 formatting, I think that it's a good idea to allow for microseconds 👍

[tsalo]

After looking through RFC3339, it looks like it's optional to include fractional seconds, so that should be okay. I think, for the specification, we just need to prescribe a specific number of digits for consistency. Python's datetime module uses 6 decimal points by default for the ISO format, and since a lot of users use heudiconv, which relies on datetime for date-time formatting, that might be a good standard to use. WDYT?

[sappelhoff]

I had a quick look as well and apparently neither RFC3339 nor ISO 8601 prescribe a number of decimal points for the fractional seconds.

I am personally fine with 6, because it seems unrealistic that any application would need to be more precise than that. What do you think @nicholst ?

If we are prescribing a number of decimal points for consistency, we might as well prescribe the use of . instead of , as the separator (the standards apparently allow both)

[nicholst]

I'm for prescribing . over , but wonder if we need to prescribe the number of digits... I'd be inclined to leave the number of digits to the user. (Don't see how that would cause parsing headaches)

[tsalo]

Thank you both for working through it. I'll open a PR ASAP.

[yarikoptic]

+1 on arbitrary precision after . following the standard . IMHO there is no need to over-specify.