`get_ts_from_sentinel_filename()` does not return a defined date format about ukis-pysat

[nmandery]

I think it shoud return a datetime object instead of a string. That would be the appropriate type.

[fwfichtner]

I think it shoud return a datetime object instead of a string. That would be the appropriate type.

Yes, that's better.

[BoehnkeC]

Would you also like to have information about the timezone? All timestamps are GMT but do you like to have it as additional information?

[nmandery]

It should be as complete as possible - so with timezone please. Not erverybody knows about the GMT timeszone being the default for Sentinel. Also the timestamps will get used in applications where it is not clear anymore that it came from a sentinel scene and must be GMT.

[BoehnkeC]

We had some confusion with the Sentinel-2 nomenclature. Regarding the naming conventions for Sentinel-2, the ESA proposed this new scheme for Sentinel-2 level 1C scenes acquired since December 16, 2016:
MMM_MSIXXX_YYYYMMDDHHMMSS_Nxxyy_ROOO_Txxxxx_<Product Discriminator>.SAFE.

It appeared, that the omnipresent T was not part of the sensing timestamp anymore. However, a bit further down the new scheme was explained with this example:
S2A_MSIL1C_20170105T013442_N0204_R031_T53NMJ_20170105T013443.SAFE with T being used again as delimiter for date and time.

A check with two scenes from 2016 and 2020 revealed equal naming schemes so I assume we won't get any trouble:
S2A_MSIL1C_20200603T103031_N0209_R108_T32UMA_20200603T155047
S2A_MSIL1C_20160803T103032_N0204_R108_T32UNA_20160803T103026

@MWieland can you confirm that?

[MWieland]

Yes I can confirm the observations of @BoehnkeC . The name convention in the style S2A_MSIL1C_20200603T103031_N0209_R108_T32UMA_20200603T155047 seems to be standard.