Date overhaul?

One of the other driving factors to over-haul the default date handling is that floats do not have enough precision to deal with nano-second resolution data (which is what I think drove pandas to use datetime64).

It sounds like the correct solution

Is the unit framework documented anywhere and are those custom classes public?

Tom

···

On Thu, Jan 8, 2015 at 7:04 AM, Skip Montanaro
<skip@…503…> wrote:

I’m real naive about this stuff, but I have always wondered why

matplotlib didn’t just use datetime objects, or at least use

timezone-aware datetime objects as an “interchange” format to get the

timezone stuff right.

Time zone handling is a pain in the %}€*

And the definitions keep changing.

So you need a complex DB and library that needs frequent updating.

This is why neither the standard library nor numpy support time zone handling out of the box.

But the datetime object does support a hook to add timezone info.

The numpy datetime64 may implementation may provide a similar hook in the future.

There is the pytz package, which MPL could choose to depend on.

But even that is a bit ugly–e.g. from the pytz docs:

“”“Unfortunately using the tzinfo argument of the standard datetime constructors ‘’does not work’’ with pytz for many timezones.”“”

So my suggestion is that MPL punts, and stick with leaving time zone handling up to the user, I.e only use datetimes that are timezone “naive”. What this means is that MPL would always a assume all datetimes interacting with
each other are in the same time zone (including same DST status).

Anyway, I’m being a bit lazy here, so I may be wrong, but I think the issue at hand is that MPL currently uses a float array to store and manipulate datetimes, and the thought is that it may be better to use
numpy datetime64 arrays – that would give us more consistent precision, and less code to convert to/from various datetime formats.

I’m a bit on the fence about whether it’s time to do it, as datetime64 does have issues with the locale timezone, but as any implementation would want to work with not-just-the-latest numpy anyway, it may make sense to start now.
-Chris

Christopher Barker, Ph.D.

Oceanographer

Emergency Response Division

NOAA/NOS/OR&R (206) 526-6959 voice

7600 Sand Point Way NE (206) 526-6329 fax

Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@…272…236…

Google search “matplotlib units” yields: http://matplotlib.org/api/units_api.html

So it sounds like the update is to make MPL’s internal date system higher resolution which would be great. We would just need to update our converters to convert to that format instead of the current floating point format. Our custom classes are not public
(and can’t really be made public) but they aren’t very complicated so we can certainly talk about the implementation if that helps.

···

On Thu, Jan 8, 2015 at 7:04 AM, Skip Montanaro
<skip@…503…> wrote:

I’m real naive about this stuff, but I have always wondered why

matplotlib didn’t just use datetime objects, or at least use

timezone-aware datetime objects as an “interchange” format to get the

timezone stuff right.

Time zone handling is a pain in the %}€*

And the definitions keep changing.

So you need a complex DB and library that needs frequent updating.

This is why neither the standard library nor numpy support time zone handling out of the box.

But the datetime object does support a hook to add timezone info.

The numpy datetime64 may implementation may provide a similar hook in the future.

There is the pytz package, which MPL could choose to depend on.

But even that is a bit ugly–e.g. from the pytz docs:

“”“Unfortunately using the tzinfo argument of the standard datetime constructors ‘’does not work’’ with pytz for many timezones.”“”

So my suggestion is that MPL punts, and stick with leaving time zone handling up to the user, I.e only use datetimes that are timezone “naive”. What this means is that MPL would always a assume all datetimes interacting with
each other are in the same time zone (including same DST status).

Anyway, I’m being a bit lazy here, so I may be wrong, but I think the issue at hand is that MPL currently uses a float array to store and manipulate datetimes, and the thought is that it may be better to use
numpy datetime64 arrays – that would give us more consistent precision, and less code to convert to/from various datetime formats.

I’m a bit on the fence about whether it’s time to do it, as datetime64 does have issues with the locale timezone, but as any implementation would want to work with not-just-the-latest numpy anyway, it may make sense to start now.
-Chris

Christopher Barker, Ph.D.

Oceanographer

Emergency Response Division

NOAA/NOS/OR&R (206) 526-6959 voice

7600 Sand Point Way NE (206) 526-6329 fax

Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@…272…236…