> This is fine. Just be aware that *naive* datetimes will also have the PEP
> 495 "fold" attribute in Python 3.6. You are free to ignore it, but you will
> loose the ability to round-trip between naive stdlib datetimes and
> numpy.datetime64.
Sigh. I can see why it's there ( primarily to supp
On Mon, Oct 19, 2015 at 4:12 PM, Stephan Hoyer wrote:
> On Mon, Oct 19, 2015 at 12:34 PM, Chris Barker
> wrote:
>
>> Also -- I think we are at phase one of a (at least) two step process:
>>
>> 1) clean up datetime64 just enough that it is useful, and less
>> error-prone -- i.e. have it not prete
On Mon, Oct 19, 2015 at 4:12 PM, Stephan Hoyer wrote:
> Alexander -- by "mst" I think Chris meant "most".
Good because in context it could be "Moscow Standard Time" or "Mean Solar
Time". :-)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
On Mon, Oct 19, 2015 at 12:34 PM, Chris Barker
wrote:
> Also -- I think we are at phase one of a (at least) two step process:
>
> 1) clean up datetime64 just enough that it is useful, and less error-prone
> -- i.e. have it not pretend to support anything other than naive datetimes.
>
> 2) Do it r
On Mon, Oct 19, 2015 at 3:34 PM, Chris Barker wrote:
>
> > In Python 3.6, datetime.now() will return different values in the first
> and the second repeated hour in the "fall-back fold." > If you allow
> datetime.datetime to numpy.datetime64 conversion, you should decide what
> you do with that d
On Mon, Oct 19, 2015 at 3:34 PM, Chris Barker wrote:
> DST is a civil construct -- and mst (all?) implementations use the
> convention of having repeated times.
What is "mst"?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.s
On Sun, Oct 18, 2015 at 12:20 PM, Alexander Belopolsky
wrote:
>
> On Sat, Oct 17, 2015 at 6:59 PM, Chris Barker
> wrote:
>
>> Off the top of my head, I think allowing a 60th second makes more sense
>> -- jsut like we do leap years.
>
>
> Yet we don't implement DST by allowing the 24th hour. Eve
On Sat, Oct 17, 2015 at 6:59 PM, Chris Barker wrote:
> If anyone decides to actually get around to leap seconds support in numpy
> datetime, s/he can decide ...
This attitude is the reason why we will probably never have bug free
software when it comes to civil time reckoning. Even though ANS
On Sat, Oct 17, 2015 at 6:59 PM, Chris Barker wrote:
> Off the top of my head, I think allowing a 60th second makes more sense --
> jsut like we do leap years.
Yet we don't implement DST by allowing the 24th hour. Even the countries
that adjust the clocks at midnight don't do that.
In some se
On Fri, Oct 16, 2015 at 10:19 AM, Alexander Belopolsky
wrote:
> Since Guido hates leap seconds, PEP 495 is silent on this issue, but
> strictly speaking UTC leap seconds are "folds." AFAICT, a strictly POSIX
> system must repeat the same value of time_t when a leap second is
> inserted. While
On Tue, Oct 13, 2015 at 6:48 PM, Chris Barker wrote:
> And because we probably want fast absolute delta computation, when we add
> timezones, we'll probably want to store the datetime in UTC, and apply the
> timezone on I/O.
>
> Alexander: Am I right that we don't need the "fold" bit in this case
On Wed, Oct 14, 2015 at 10:34 AM, Phil Hodge wrote:
> On 10/14/2015 11:59 AM, Chris Barker wrote:
>
>> we have no way to know when there will be leap-seconds in the future
>>
>
> Leap seconds are announced about six months in advance.
exactly -- so more than six month, we have no idea.
and eve
On 10/14/2015 11:59 AM, Chris Barker wrote:
we have no way to know when there will be leap-seconds in the future
Leap seconds are announced about six months in advance.
Phil
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.sc
On Tue, Oct 13, 2015 at 5:08 PM, Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Maybe not directly relevant, but also very clearly why one should ideally
>> not use these a
>>
> all!
>>
> I wouldn't say not at all -- I'd say "not in some circumstances"
> Perhaps even less relevant, but
On Tue, Oct 13, 2015 at 3:58 PM, Nathaniel Smith wrote:
> > However, numpy datetime is optimized for compact storage and fast
> computation of absolute deltas (actual hours, minutes, seconds... not
> calendar units like "the next day" ).
>
> Except that ironically it actually can't compute absolu
>
> > However, numpy datetime is optimized for compact storage and fast
> computation of absolute deltas (actual hours, minutes, seconds... not
> calendar units like "the next day" ).
>
> Except that ironically it actually can't compute absolute deltas
> accurately with one second resolution, becau
On Oct 13, 2015 3:49 PM, "Chris Barker" wrote:
>
[...]
> However, numpy datetime is optimized for compact storage and fast
computation of absolute deltas (actual hours, minutes, seconds... not
calendar units like "the next day" ).
Except that ironically it actually can't compute absolute deltas a
On Tue, Oct 13, 2015 at 3:21 PM, Nathaniel Smith wrote:
> > If you are going to make datetime64 more like datetime.datetime, please
> consider adding the "fold" bit. See PEP 495. [1]
>
The challenge here is that we literally do not have a bit too use :-)
>
hmm -- I was first thinking that this
On Oct 12, 2015 11:48 AM, "Alexander Belopolsky" wrote:
>
>
> On Mon, Oct 12, 2015 at 3:10 AM, Stephan Hoyer wrote:
>>
>> The tentative consensus from last year's discussion was that we should
make datetime64 timezone naive, like the standard library's
datetime.datetime
>
>
>
> If you are going t
On Mon, Oct 12, 2015 at 12:38 AM, Nathaniel Smith wrote:
> > As a temporary measure, we still will parse datetimes that include a
> > timezone specification by converting them to UTC, but will issue a
> > DeprecationWarning. This is important for a smooth transition, because at
> > the very least
On Mon, Oct 12, 2015 at 11:48 AM, Alexander Belopolsky
wrote:
> If you are going to make datetime64 more like datetime.datetime, please
> consider adding the "fold" bit. See PEP 495. [1]
>
> [1]: https://www.python.org/dev/peps/pep-0495/
>
well, adding any timezone support is not (yet) in the t
On Mon, Oct 12, 2015 at 12:38 AM, Nathaniel Smith wrote:
>
> One possible strategy here would be to do some corpus analysis to find
> out whether anyone is actually using it, like I did for the ufunc ABI
> stuff:
> https://github.com/njsmith/codetrawl
> https://github.com/njsmith/ufunc-abi-an
I'd be totally in support of switching to timezone naive form. While it
would be ideal that everyone stores their dates in UTC, the real world is
messy and most of the time, people are just loading dates as-is and don't
even care about timezones. I work on machines with different TZs, and I
hate it
On Mon, Oct 12, 2015 at 3:10 AM, Stephan Hoyer wrote:
> The tentative consensus from last year's discussion was that we should
> make datetime64 timezone naive, like the standard library's
> datetime.datetime
If you are going to make datetime64 more like datetime.datetime, please
consider addi
On Mon, Oct 12, 2015 at 12:10 AM, Stephan Hoyer wrote:
> As has come up repeatedly over the past few years, nobody seems to be very
> happy with the way that NumPy's datetime64 type parses and prints datetimes
> in local timezones.
>
> The tentative consensus from last year's discussion was that w
As has come up repeatedly over the past few years, nobody seems to be very
happy with the way that NumPy's datetime64 type parses and prints datetimes
in local timezones.
The tentative consensus from last year's discussion was that we should make
datetime64 timezone naive, like the standard librar
26 matches
Mail list logo