Re: [Numpy-discussion] Making datetime64 timezone naive

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

Re: [Numpy-discussion] Making datetime64 timezone naive

> 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

Re: [Numpy-discussion] Making datetime64 timezone naive

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

Re: [Numpy-discussion] Making datetime64 timezone naive

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

Re: [Numpy-discussion] Making datetime64 timezone naive

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 >

Re: [Numpy-discussion] Making datetime64 timezone naive

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

Re: [Numpy-discussion] Making datetime64 timezone naive

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

Re: [Numpy-discussion] Making datetime64 timezone naive

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,

Re: [Numpy-discussion] Making datetime64 timezone naive

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

Re: [Numpy-discussion] Making datetime64 timezone naive

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

Re: [Numpy-discussion] Making datetime64 timezone naive

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 >

Re: [Numpy-discussion] Making datetime64 timezone naive

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

Re: [Numpy-discussion] Making datetime64 timezone naive

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

Re: [Numpy-discussion] Making datetime64 timezone naive

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 >

Re: [Numpy-discussion] Making datetime64 timezone naive

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

Re: [Numpy-discussion] Making datetime64 timezone naive

> > > 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,

Re: [Numpy-discussion] Making datetime64 timezone naive

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

Re: [Numpy-discussion] Making datetime64 timezone naive

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

[Numpy-discussion] Making datetime64 timezone naive

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

Re: [Numpy-discussion] Making datetime64 timezone naive

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

Re: [Numpy-discussion] Making datetime64 timezone naive

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,