Re: [Numpy-discussion] Dates and times and Datetime64 (again)

2014-03-21 Thread Chris Barker
On Thu, Mar 20, 2014 at 4:55 PM, Sankarshan Mudkavi smudk...@uwaterloo.cawrote: Yes 2) is indeed what I was suggesting. My apologies for being unclear, I was unsure of how much detail and technical information I should include in the proposal. well, you need to put enough in that it's clear

Re: [Numpy-discussion] Dates and times and Datetime64 (again)

2014-03-21 Thread Chris Barker
On Thu, Mar 20, 2014 at 5:53 PM, Alexander Belopolsky ndar...@mac.comwrote: I recall that it was at some point suggested that epoch be part of dtype. I was not able to find the reasons for a rejection, I don't think it was rejected, it just wasn't adopted by anyone to write a NEP and write

Re: [Numpy-discussion] Dates and times and Datetime64 (again)

2014-03-21 Thread Chris Barker
On Thu, Mar 20, 2014 at 6:32 PM, Alexander Belopolsky ndar...@mac.comwrote: The difference comes down to I/O. It is more than I/O. It is also about interoperability with Python's datetime module. Sorry -- I was using I/O to mean converting to/from datetime64 and other types So that

Re: [Numpy-discussion] Dates and times and Datetime64 (again)

2014-03-21 Thread Alexander Belopolsky
On Fri, Mar 21, 2014 at 5:31 PM, Chris Barker chris.bar...@noaa.gov wrote: But this brings up a good point -- having time zone handling fully compatible ith datetime.datetime would have its advantages. I don't know if everyone is aware of this, but Python stdlib has support for fixed-offset

Re: [Numpy-discussion] Dates and times and Datetime64 (again)

2014-03-21 Thread Nathaniel Smith
On Thu, Mar 20, 2014 at 11:27 PM, Chris Barker chris.bar...@noaa.gov wrote: * I think there are more or less three options: 1) a) don't have any timezone handling at all -- all datetime64s are UTC. Always b) don't have any timezone handling at all -- all datetime64s are naive

[Numpy-discussion] unique return_index order?

2014-03-21 Thread Alan G Isaac
The documentation of numpy.unique http://docs.scipy.org/doc/numpy/reference/generated/numpy.unique.html does not seem to promise that return_index=True will always index the *first* occurrence of each unique item, which I believe is the current behavior. A promise would be nice. Is it intended?

Re: [Numpy-discussion] unique return_index order?

2014-03-21 Thread Charles R Harris
On Fri, Mar 21, 2014 at 6:49 PM, josef.p...@gmail.com wrote: On Fri, Mar 21, 2014 at 8:46 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Fri, Mar 21, 2014 at 6:26 PM, Alan G Isaac alan.is...@gmail.comwrote: The documentation of numpy.unique

Re: [Numpy-discussion] unique return_index order?

2014-03-21 Thread josef . pktd
On Fri, Mar 21, 2014 at 9:01 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Fri, Mar 21, 2014 at 6:49 PM, josef.p...@gmail.com wrote: On Fri, Mar 21, 2014 at 8:46 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Fri, Mar 21, 2014 at 6:26 PM, Alan G Isaac

Re: [Numpy-discussion] unique return_index order?

2014-03-21 Thread josef . pktd
On Fri, Mar 21, 2014 at 9:27 PM, josef.p...@gmail.com wrote: On Fri, Mar 21, 2014 at 9:01 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Fri, Mar 21, 2014 at 6:49 PM, josef.p...@gmail.com wrote: On Fri, Mar 21, 2014 at 8:46 PM, Charles R Harris