Actually quarters (3 months sub-year groupings) are already supported as
‘M8[3M]’ and ‘m8[3M]’:
>>> np.datetime64('2024-05').astype('M8[3M]') -
np.datetime64('2020-03').astype('M8[3M]')
numpy.timedelta64(17,'3M')
So explicitly introducing a ‘Q’ time unit is only to enable more intuitive
representation/parsing of dates and durations.I’m moderately negative on this proposal: - there is no native support of quarters in Python - ISO 8601-1 does not support sub-year groupings - the ISO 8601-2 extensions representing sub-year groupings is not sufficiently widespread to be adopted by numpy. (E.g. '2001-34' expresses "second quarter of 2001”, but I suppose nobody would guess this meaning) In other words, without a clear normative reference, implementing quarters in numpy would risk to introduce a custom/arbitrary notation. Stefano
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
