On Thu, Apr 4, 2013 at 12: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 attos
>
>
Sorry, having trouble keeping up with this thread!
Comments, specific to my (limited) use-cases are inline:
Chris Barker - NOAA Federal noaa.gov> writes:
>
>
> I thought about that -- but if you have timedelta without datetime,
> you really just have an integer -- we haven't bought anythin
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 4/4/13 8:56 PM, Chris Barker - NOAA Federal wrote:
> On Thu, Apr 4, 2013 at 10:54 AM, Francesc Alted 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]') + np.array(1,
>> dtype='
On Thu, Apr 4, 2013 at 10:54 AM, Francesc Alted 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]') + np.array(1,
> dtype='timedelta64[ns]')
> Out[]: numpy.datetime64('2017-07-14T04:40:
On Thu, Apr 4, 2013 at 10:54 AM, Francesc Alted wrote:
> On 4/4/13 7:01 PM, Chris Barker - NOAA Federal wrote:
>> I thought about that -- but if you have timedelta without datetime,
>> you really just have an integer -- we haven't bought anything.
>
> Well, it is not just an integer. It is an in
On 04/04/2013 05: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. Furthermore, UTC cannot be
> computed unambiguously for times in the future because the leap second
> insertion is not scheduled regula
On 4/4/13 7:01 PM, Chris Barker - NOAA Federal wrote:
> Francesc Alted wrote:
>> When Ivan and me were discussing that, I remember us deciding that such
>> a small units would be useful mainly for the timedelta datatype, which
>> is a relative, not absolute time. We did not want to make short for
On Thu, Apr 4, 2013 at 6:06 PM, Charles R Harris
wrote:
>
>
> On Thu, Apr 4, 2013 at 11:01 AM, Chris Barker - NOAA Federal
> wrote:
>>
>> On Wed, Apr 3, 2013 at 6:02 PM, Mark Wiebe wrote:
>> > One problem with trying to give technically correct answers for the
>> > UTC/Posix format is that it ca
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 wrote:
> > On Wed, Apr 3, 2013 at 4:27 PM, Pauli Virtanen wrote:
>
> >> Probably also TAI and UTC/Posix.
> >>
> >> Converting from one format to the other is
On Wed, Apr 3, 2013 at 6:02 PM, Mark Wiebe wrote:
> On Wed, Apr 3, 2013 at 4:27 PM, 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 dat
On 4/4/13 1:54 PM, Nathaniel Smith wrote:
> On Thu, Apr 4, 2013 at 12: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 datetime6
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 di
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 Thu, Apr 4, 2013 at 12: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 attosec
On 4 April 2013 11:03, Daniele Nicolodi 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 ignore this issue
(
On 04/04/2013 03:02, Mark Wiebe wrote:
> I think it's most straightforward to leave it wrong for Posix-format
> datetimes, but add a TAI timezone where it will produce correct results.
Strictly speaking, TAI is not a timezone but a different time base.
Cheers,
Daniele
___
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, `
On 4/3/13, Benjamin Root 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
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 le
On Wed, Apr 3, 2013 at 4:27 PM, Pauli Virtanen wrote:
> Mark Wiebe gmail.com> writes:
> > It seems to me that adding a time zone to the datetime64
> > metadata might be a good idea, and then allowing it to be
> > None to behave like the Python naive datetimes.
>
> Probably also TAI and UTC/Posix
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 different epochs. How can it
possible be useful to use nanoseconds,
Mark Wiebe gmail.com> writes:
> It seems to me that adding a time zone to the datetime64
> metadata might be a good idea, and then allowing it to be
> None to behave like the Python naive datetimes.
Probably also TAI and UTC/Posix.
Converting from one format to the other is problematic since
all
On Wed, Apr 3, 2013 at 9:33 AM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
> 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
Travis Oliphant continuum.io> writes:
>
>
> 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 pursui
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 a
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 object without a TZ is int
Nathaniel Smith pobox.com> writes:
>
> On Wed, Apr 3, 2013 at 2:26 PM, Dave Hirschfeld
> 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
> > by setting t
On Wed, Apr 3, 2013 at 2:26 PM, Dave Hirschfeld
wrote:
> Andreas Hilboll 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
>>
Andreas Hilboll 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 t
Chris Barker - NOAA Federal noaa.gov> writes:
[clip]
> actually, I think datetime64 is naive -- the problem is entirely the I/O
It's a counter from unix epoch, but as it's just an integer you can
probably redefine the epoch and pretend your local time is UTC
(as long as you don't care about DST e
>> As I poke at this a bit, I"m 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 representation -- maybe nothing inside at all.
>>
>> Does t
On Tue, Apr 2, 2013 at 2:39 PM, Pauli Virtanen 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, and "20
02.04.2013 22:42, Chris Barker - NOAA Federal kirjoitti:
[clip]
> As I poke at this a bit, I"m 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
Hey folks,
We've recently run into some issues with time zones and datetime64 (in
numpy 1.7). Specifically, there no longer seems to be a way to have
what the python datetime module calls "naive" datetime objects -- i.e.
ones that have no awareness of timezones. Moreover, datetime64 seems
to enfor
35 matches
Mail list logo
