Discussion on time is endless! (Sorry for the extra noise, on the mailing list, but I would clarify some points.)
If I got it right, np.datetime64 is defined by these points. 1) Internal representation: 64bit signed integer *plus* a time unit. The time unit can be expressed as - a SI valid unit (SI second and all decimal subunits up to the attosecond) - a SI acceptable unit (minute, hour, day) - a date unit (week, month, year) 2) Conversion routines: a bijective map from the internal representation to a proleptic Gregorian calendar [0] assuming a fixed epoch of 1970-01-01T00:00Z. The mapping neglects leap seconds and is not time-zone aware. I think that the current choice of 2) is a sensible one: I agree with Dan that it is useful to a wide audience, easy to compute, not ambiguous. I would discourage any attempt to implement in numpy more complex mappings, which are aware of time-zones and leap seconds, and why not, of the wide array of other time scales and time representation in use: this is a very complex task, and a nightmare from the point of view of maintenance. Other specialised libraries exist, like astropy.time [1] or dateutil [2] to this purpose. However the docs of numpy.datetime64 should be updated, to explicitly mention the use of the proleptic Gregorian calendar, and better clarify how the date units (month, year) are handled when casted to other shorter units like seconds, etc. Stefano [0] https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar [1] https://docs.astropy.org/en/stable/time/ [2] https://dateutil.readthedocs.io/en/stable/
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
