We are now starting the progress of trying to improve the situation with creating custom dtypes. There will actually be discussions about this end of next week (in Berkeley). But in any case I would be very interested in your specific use-case and needs, and hopefully we can help you also on your end with the current situation. We can discuss on the list, or get in contact privately.
Unfortunately, I'm in NYC, but I'd be happy to participate however I can, whether it is to describe my use case, or help writing docs, or just chat. Here's some info about my project: Ora (https://github.com/alexhsamuel/ora/ <https://github.com/alexhsamuel/ora/>) is a new date/time implementation. The intention is to provide types with ticks-since-epoch representation (rather than YMD, HMS) with full functionality for both standalone scalar (i.e. no NumPy) and ndarray use cases. Essentially, the convenience of datetime, with the performance of datetime64, and much of dateutil rolled in. I've also experimented with a number of other matters, including variable width/precision/range types. As a result I provide various time, date, and time-of-day types, for instance 32-, 64-, and 128-bit time types, and each has a corresponding dtype and complete NumPy support. It's possible to adjust this set of types, if you are willing to recompile (C++). That's why I'm interested in how dtypes are managed globally. Ora has a lot of functionality that works well, and performance is good, though it's so far a solo project and there are still lots of rough edges / missing features / bugs. I'd love to get feedback from people who work with dates and times a lot, either scalar or vectorized. My wish list for NumPy's dtype support is, - better docs on writing dtypes (though they are not bad) - ability to use a scalar type that doesn't derive from a NumPy base type, so that the scalar type can be used without importing NumPy - clear management for dtypes Please let me know how best I could participate or help. Regards, Alex