Skip to content

Datetime dev 2 #93

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 14 commits into from
Jun 22, 2011
Merged

Datetime dev 2 #93

merged 14 commits into from
Jun 22, 2011

Conversation

mwiebe
Copy link
Member

@mwiebe mwiebe commented Jun 21, 2011

This pull request includes the following modifications:

  • Tighten up date unit vs time unit casting rules, and integrate the NPY_CASTING enum deeper into the datetime conversions
  • Determine a unit when converting from a string array, similar to when converting from lists of strings
  • Switch local/utc handling to a timezone= parameter, which also accepts a datetime.tzinfo object. This, for example, enables the use of the pytz library with numpy.datetime64
  • Remove the events metadata, make the old API functions raise exceptions, and rename the "frequency" metadata name to "timeunit"
  • Abstract the flexible dtype mechanism into a function, so that it can be more easily changed without having to add code to many places

Mark Wiebe added 13 commits June 16, 2011 16:02
Also move datetime string functions to their own source file.
…string

Also add some tests using the pytz library.
…tions

Also clean up the tests to work with the stricter date unit vs time unit
boundary that has been added.
The events don't fit well within the datetime, causing many special
cases and complicating the datetime code. A better way to proceed,
which received approval from Travis with regard to the reason events
were introduced in the first place, is to do the following:

* Generalize the structured arrays so they work with ufuncs
* Either use NPY_UBYTE, or introduce a new integer modulo N type
* The structured dtype [('date', 'M8[D]'), ('event', 'u8')], then
  will operate identically to the design of events in datetime.

These other changes will have much use elsewhere as well.
The default is 'same_kind', which allows data loss, but prevents
crossing the date unit/time unit boundary. As a special case,
printing dates with a timezone specified requires 'unsafe' casting.
…tion

Since the datetime adds a new flexible dtype (datetime with generic units),
updating all the places where flexible dtypes are adjusted was error-prone.
Thus, this has been moved to a single place.

At the same time, I've added sizes for the various number types, so
they don't produce size-one strings by default anymore
* unrecognized inputs are converted to 'NaT' instead of throwing an error,
* while with 'safe' casting an error will be thrown if any precision
* from the input will be thrown away.
*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are the casting rules described in more detail somewhere?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not at the moment, but it should go in the documentation, yes.

@charris
Copy link
Member

charris commented Jun 21, 2011

Look like things are coming together.

@charris
Copy link
Member

charris commented Jun 22, 2011

I'm OK with this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants