On Thu, Apr 4, 2013 at 12:52 AM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
Thanks all for taking an interest. I need to think a bot more about
the options before commenting more, but:
while we're at it:
It seems very odd to me that datetime64 supports different units
(right
On 04/04/2013 15:34, Jonathan T. Niehof wrote:
Keeping a leap second database up to date is annoying but not as bad as
it could be: they're not arbitrary. Although they can occur monthly,
they've only ever happened at June 30 and Dec 31, announced in January
and July, respectively. So it
On 04/04/2013 01:27, Pauli Virtanen wrote:
Probably also TAI and UTC/Posix.
Converting from one format to the other is problematic since
all of them (except TAI afaik) require looking things up in
regularly updated databases. Not only restricted to conversions,
but also arithmetic, `b -
On 4 April 2013 11:03, Daniele Nicolodi dani...@grinta.net wrote:
I think that generally the issue is not relevant for any practical use
of a timebase: there are not many applications requiring sub-second
accuracy over many years periods.
I agree. I think the basic datetime object should
On Thu, Apr 4, 2013 at 12:52 AM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
Thanks all for taking an interest. I need to think a bot more about
the options before commenting more, but:
while we're at it:
It seems very odd to me that datetime64 supports different units
(right
On 04/04/2013 03:03 AM, Daniele Nicolodi wrote:
I'm not aware of any library that handles the conversion from UTC to
TAI. I would like to know if there is one.
The CDF library does, although that's rather a sledgehammer to drive a
thumbtack.
I think that generally the issue is not relevant
On 4/4/13 1:52 AM, Chris Barker - NOAA Federal wrote:
Thanks all for taking an interest. I need to think a bot more about
the options before commenting more, but:
while we're at it:
It seems very odd to me that datetime64 supports different units
(right down to attosecond) but not
On 4/4/13 1:54 PM, Nathaniel Smith wrote:
On Thu, Apr 4, 2013 at 12:52 AM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
Thanks all for taking an interest. I need to think a bot more about
the options before commenting more, but:
while we're at it:
It seems very odd to me that
On Wed, Apr 3, 2013 at 6:02 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Wed, Apr 3, 2013 at 4:27 PM, Pauli Virtanen p...@iki.fi wrote:
Probably also TAI and UTC/Posix.
Converting from one format to the other is problematic since
all of them (except TAI afaik) require looking things up in
On Thu, Apr 4, 2013 at 11:01 AM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
On Wed, Apr 3, 2013 at 6:02 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Wed, Apr 3, 2013 at 4:27 PM, Pauli Virtanen p...@iki.fi wrote:
Probably also TAI and UTC/Posix.
Converting from one format to
On Thu, Apr 4, 2013 at 6:06 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Thu, Apr 4, 2013 at 11:01 AM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
On Wed, Apr 3, 2013 at 6:02 PM, Mark Wiebe mwwi...@gmail.com wrote:
One problem with trying to give technically
On 4/4/13 8:56 PM, Chris Barker - NOAA Federal wrote:
On Thu, Apr 4, 2013 at 10:54 AM, Francesc Alted franc...@continuum.io wrote:
That makes a difference. This can be specially important for creating
user-defined time origins:
In []: np.array(int(1.5e9), dtype='datetime64[s]') +
Andreas Hilboll lists at hilboll.de writes:
I think your point about using current timezone in interpreting user
input being dangerous is probably correct --- perhaps UTC all the way
would be a safer (and simpler) choice?
+1
+10 from me!
I've recently come across a bug due to
On Wed, Apr 3, 2013 at 2:26 PM, Dave Hirschfeld
dave.hirschf...@gmail.com wrote:
Andreas Hilboll lists at hilboll.de writes:
I think your point about using current timezone in interpreting user
input being dangerous is probably correct --- perhaps UTC all the way
would be a safer (and
Nathaniel Smith njs at pobox.com writes:
On Wed, Apr 3, 2013 at 2:26 PM, Dave Hirschfeld
dave.hirschfeld at gmail.com wrote:
This isn't acceptable for my use case (in a multinational company) and I
found
no reasonable way around it other than bypassing the numpy conversion
entirely
dave.hirschf...@gmail.com wrote:
I found no reasonable way around it other than bypassing the numpy
conversion entirely
Exactly - we have come to the same conclusion. By the way, it's also
consistent -- an ISO string without a TZ is interpreted as a to mean
use the locale, but a datetime
Mark Wiebe and I are both still tracking NumPy development and can provide
context and even help when needed.Apologies if we've left a different
impression. We have to be prudent about the time we spend as we have
other projects we are pursuing as well, but we help clients with NumPy
issues
On Wed, Apr 3, 2013 at 9:33 AM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
dave.hirschf...@gmail.com wrote:
I found no reasonable way around it other than bypassing the numpy
conversion entirely
Exactly - we have come to the same conclusion. By the way, it's also
consistent
On Wed, Apr 3, 2013 at 7:52 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
Personally, I never need finer resolution than seconds, nor more than
a century, so it's no big deal to me, but just wondering
A use case for finer resolution than seconds (in our field, no less!)
On 4/3/13, Benjamin Root ben.r...@ou.edu wrote:
On Wed, Apr 3, 2013 at 7:52 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
Personally, I never need finer resolution than seconds, nor more than
a century, so it's no big deal to me, but just wondering
A use case for finer
02.04.2013 22:42, Chris Barker - NOAA Federal kirjoitti:
[clip]
As I poke at this a bit, Im noticing that maybe time zones aren't
handles at all internally -- rather, the conversion is done to UTC
when creating a datetime64, and conversion is then done to the locale
when creating a strng
On Tue, Apr 2, 2013 at 2:39 PM, Pauli Virtanen p...@iki.fi wrote:
As far as I understand (more knowledgeable people, please correct me),
Numpy's datetime handling in 1.7 is timezone-agnostic and works in UTC
(which is not a time zone). That is, datetime64 represents an absolute
point in time,
22 matches
Mail list logo
