Re: [Numpy-discussion] Time Zones and datetime64

On Fri, Apr 12, 2013 at 1:36 PM, Anthony Scopatz wrote: > Option (2), what datetime does, is the wrong model. This is more > complicated in both the implementation and API, and leads to lots of broken > code, weird errors, and no clear right way of doing thing. could you elaborate a bit more? I'

Re: [Numpy-discussion] Time Zones and datetime64

Colin J. Williams gmail.com> writes: > well, I don't see any timezone support in there at all. It appears the > use UTC, though I"m not entierly sure from the docs what now() would > return. > > So I think it's pretty much like my "use UTC" proposal. I think so. There is no support for leap sec

Re: [Numpy-discussion] Time Zones and datetime64

On 12/04/2013 3:57 PM, Chris Barker - NOAA Federal wrote: On Fri, Apr 12, 2013 at 9:52 AM, Riccardo De Maria wrote: Not related to leap seconds and physically accurate time deltas, I have just noticed that SQLite has a nice API: http://www.sqlite.o

Re: [Numpy-discussion] Time Zones and datetime64

Thanks for putting this together Chris. I am in favor of option (1) Pure UTC. I think it is the simplest to implement, and to get from / to other time zones is one ufunc application. On the other hand, option (3) full time zone support isn't too bad either. It is more work to implement but a lo

Re: [Numpy-discussion] Time Zones and datetime64

On Fri, Apr 12, 2013 at 9:52 AM, Riccardo De Maria wrote: > Not related to leap seconds and physically accurate time deltas, I have just > noticed that SQLite has a nice API: > > http://www.sqlite.org/lang_datefunc.html > > that one can be inspired from. The source contains a date.c which looks >

Re: [Numpy-discussion] Time Zones and datetime64

Not related to leap seconds and physically accurate time deltas, I have just noticed that SQLite has a nice API: http://www.sqlite.org/lang_datefunc.html that one can be inspired from. The source contains a date.c which looks reasonably clear. Riccardo __

Re: [Numpy-discussion] Time Zones and datetime64

Daniele Nicolodi grinta.net> writes: > > On 10/04/2013 18:55, Riccardo De Maria wrote: > > The library should handle correctly leap seconds, otherwise using unix time > > as a floating point number is already sufficient for many applications. > > Please define what you mean by "handle correctly

Re: [Numpy-discussion] Time Zones and datetime64

On Wed, Apr 10, 2013 at 9:55 AM, Riccardo De Maria wrote: > The library should handle correctly leap seconds, otherwise using unix time > as a floating point number is already sufficient for many applications. well, we could have used floating point in datetime64, but integers have their advanta

Re: [Numpy-discussion] Time Zones and datetime64

On 10/04/2013 18:55, Riccardo De Maria wrote: > The library should handle correctly leap seconds, otherwise using unix time > as a floating point number is already sufficient for many applications. Please define what you mean by "handle correctly leap seconds". As leap seconds are not predictable

Re: [Numpy-discussion] Time Zones and datetime64

Thanks for the effort. I think one should assume UTC when the time zones are not explicit. The library should handle correctly leap seconds, otherwise using unix time as a floating point number is already sufficient for many applications. Did you have a look to http://cr.yp.to/libtai.html? Ric

Re: [Numpy-discussion] Time Zones and datetime64

On Wed, Apr 10, 2013 at 4:21 AM, Colin J. Williams wrote: > On Mon, Apr 8, 2013 at 12:24 PM, Chris Barker - NOAA Federal >> Recent discussion has made it clear that the timezone handling in the >> current (numpy1.7) version of datetime64 is broken. Below is a >> discussion of some possible solutio

Re: [Numpy-discussion] Time Zones and datetime64

On 09/04/2013 5:46 PM, Mark Wiebe wrote: On Mon, Apr 8, 2013 at 12:24 PM, Chris Barker - NOAA Federal wrote: Recent discussion has made it clear that the timezone handling in

Re: [Numpy-discussion] Time Zones and datetime64

On Mon, Apr 8, 2013 at 12:24 PM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > Recent discussion has made it clear that the timezone handling in the > current (numpy1.7) version of datetime64 is broken. Below is a > discussion of some possible solutions, hopefully including most of

[Numpy-discussion] Time Zones and datetime64

Recent discussion has made it clear that the timezone handling in the current (numpy1.7) version of datetime64 is broken. Below is a discussion of some possible solutions, hopefully including most of the comments made on the recent thread on this list. http://mail.scipy.org/pipermail/numpy-discuss