On Sun, Feb 26, 2012 at 10:11 AM, Simon Cross
wrote:
> On Sun, Feb 26, 2012 at 6:12 PM, Larry Hastings wrote:
>> It's probably neutral. But I do have one question: can you foresee the
>> scientific community moving to a finer resolution than nanoseconds in our
>> lifetimes?
>
> I think we're alr
On Sun, Feb 26, 2012 at 6:12 PM, Larry Hastings wrote:
> It's probably neutral. But I do have one question: can you foresee the
> scientific community moving to a finer resolution than nanoseconds in our
> lifetimes?
I think we're already there. Even just in radio astronomy new arrays
like ALMA
Also, data collection will almost always be done by specialized hardware
and the data stored off for deferred processing and analysis.
Tony
On Sun, Feb 26, 2012 at 11:34 AM, Tony Koker wrote:
> my 2 cents...
>
> being in electronics for over 30 years, it is forever expanding in both
> direction
my 2 cents...
being in electronics for over 30 years, it is forever expanding in both
directions, bigger mega, giga, tera, peta, etc. AND smaller nano, pico,
femto, atto.
but, I agree that it is moot, as it is not the range, which is usually
expressed in an exponential component of the system bei
On 02/26/2012 06:51 AM, Simon Cross wrote:
There are good scientific use cases for nanosecond time resolution
(e.g. radio astronomy) where one is actually measuring time down to
that level and taking into account propagation delays. I have first
hand experience [...]
I'm not sure whether any of
On Sun, Feb 26, 2012 at 1:31 AM, Guido van Rossum wrote:
> I still think that when you are actually interested in *using* times,
> the current float format is absolutely fine. Anybody who thinks they
> need to accurately know the absolute time that something happened with
> nanosecond accuracy is
> Scratch that, *I* don't agree. timedelta is a pretty clumsy type to
> use. Have you ever tried to compute the number of seconds between two
> datetimes? You can't just use the .seconds field, you have to combine
> the .days and .seconds fields. And negative timedeltas are even harder
> due to the
> Scratch that, *I* don't agree. timedelta is a pretty clumsy type to
> use. Have you ever tried to compute the number of seconds between two
> datetimes? You can't just use the .seconds field, you have to combine
> the .days and .seconds fields. And negative timedeltas are even harder
> due to the
On 02/25/2012 03:31 PM, Guido van Rossum wrote:
On Sat, Feb 25, 2012 at 1:31 PM, Barry Warsaw wrote:
On Feb 23, 2012, at 01:28 PM, Larry Hastings wrote:
* Change the result of os.stat to be a custom class rather than a
PyStructSequence. Support the sequence protocol on the custom class bu
On Sat, Feb 25, 2012 at 1:31 PM, Barry Warsaw wrote:
> On Feb 23, 2012, at 01:28 PM, Larry Hastings wrote:
>
>>* Improve datetime.datetime objects so they support nanosecond resolution,
>> in such a way that it's 100% painless to make them even more precise in
>> the future.
>
> +1
And how wo
On Feb 23, 2012, at 01:28 PM, Larry Hastings wrote:
>* Improve datetime.datetime objects so they support nanosecond resolution,
> in such a way that it's 100% painless to make them even more precise in
> the future.
+1
>* Add support to datetime objects that allows adding and subtracting int
On Thu, Feb 23, 2012 at 3:47 PM, Larry Hastings wrote:
> On 02/23/2012 02:35 PM, Victor Stinner wrote:
> > For os.stat(), you should use the UTC timezone, not a naive datetime.
>
> Why is that more appropriate? IIUC, timestamps ignore leap seconds and
> strictly represent "seconds since the epoch
On 02/23/2012 02:35 PM, Victor Stinner wrote:
I rejected datetime.datetime because I want to get nanosecond
resolution for time and os modules, not only for the os module. If we
choose to only patch the os module (*stat() and *utime*() functions),
datetime.datetime would be meaningful (e.g. it's
I rejected datetime.datetime because I want to get nanosecond
resolution for time and os modules, not only for the os module. If we
choose to only patch the os module (*stat() and *utime*() functions),
datetime.datetime would be meaningful (e.g. it's easier to format
datetime for an human, than a E
I've been meditating on the whole os.stat mtime representation thing.
Here's a possible alternative approach.
* Improve datetime.datetime objects so they support nanosecond resolution,
in such a way that it's 100% painless to make them even more precise in
the future.
* Add support to date
15 matches
Mail list logo
