FWIW issue23084 was withdrawn as it appears to be touching and PEP
sized, and/or anyways nanosec is defacto just an int.
another patch went to http://bugs.python.org/issue15443 seemingly under
the radar, I'm not arguing the quality of the patch, but bringing it up
here in case with the holidays
done - http://bugs.python.org/issue23084
On 12/17/14 8:20 PM, Eric Snow wrote:
On Wed, Dec 17, 2014 at 7:52 PM, Matthieu Bec wrote:
Attached patch defines a new type struct_timespec for the time module. A new
capsule exports the type along with to/from converters - opening a bridge
for C, an
On Wed, Dec 17, 2014 at 7:52 PM, Matthieu Bec wrote:
>
>
> Attached patch defines a new type struct_timespec for the time module. A new
> capsule exports the type along with to/from converters - opening a bridge
> for C, and for example the datetime module.
I'd recommend opening a new issue in th
Attached patch defines a new type struct_timespec for the time module. A
new capsule exports the type along with to/from converters - opening a
bridge for C, and for example the datetime module.
Your comments welcomed. If people feel this is worth the effort and
going the right direction, I
On 12/16/14 3:31 PM, Matthieu Bec wrote:
On 12/16/14 3:28 PM, Matthieu Bec wrote:
Maybe what I meant with `nothing looks quite right':
seconds as float, microseconds as float, nanosecond as 0..999,
nanoseconds as 0..9 with mandatory keyword that precludes
microseconds - all can be m
python-n (for next) - just poking fun at the other thread
On 12/16/14 4:17 PM, Guido van Rossum wrote:
"Nothing looks quite right" is a common phenomenon when you're
constrained by backward compatibility. The perfect solution would throw
away compatibility, but that has its own downsides. So jus
"Nothing looks quite right" is a common phenomenon when you're constrained
by backward compatibility. The perfect solution would throw away
compatibility, but that has its own downsides. So just go for what looks
the least wrong.
On Tue, Dec 16, 2014 at 3:28 PM, Matthieu Bec wrote:
>
>
> Maybe wh
On 12/16/14 3:28 PM, Matthieu Bec wrote:
Maybe what I meant with `nothing looks quite right':
seconds as float, microseconds as float, nanosecond as 0..999,
nanoseconds as 0..9 with mandatory keyword that precludes
microseconds - all can be made to work, none seems completely satisfyin
Maybe what I meant with `nothing looks quite right':
seconds as float, microseconds as float, nanosecond as 0..999,
nanoseconds as 0..9 with mandatory keyword that precludes
microseconds - all can be made to work, none seems completely satisfying.
In fact, I don't really have a use fo
On Tue, Dec 16, 2014 at 12:10 PM, matthieu bec wrote:
> I wonder if the datetime module is really the right location, that has
> constructor(year, month, day, ..., second, microsecond) - with 0 no millis. adding 0 quite right.
We can make nanosecond a keyword-only argument, so that
time(1, 2,
Aren't the wrappers for the kernel's time-related structs typically in the
time module? That seems the place to start. Eventually we can support going
between those structs and the datetype datatype (the latter may have to
grow an option to specify nsec).
On Tue, Dec 16, 2014 at 11:21 AM, Matthieu
yes that was mentioned in this thread, %nN looks quite reasonable.
still, I'd like to steer the conversation back to the other aspect -
where should something like struct_timespec land in the first place, is
datetime really the best to capture that?
Most of the conversation has been revolving
I vote to copy Ruby's %N and leave %f alone.
On Tue, Dec 16, 2014 at 11:08 AM, Skip Montanaro
wrote:
>
>
> On Tue, Dec 16, 2014 at 11:10 AM, matthieu bec wrote:
> > Agreed with Antoine, strftime/strptime are somewhat different concerns.
> > Doesn't mean thay cannot be fixed at the same time but
On Tue, Dec 16, 2014 at 11:10 AM, matthieu bec wrote:
> Agreed with Antoine, strftime/strptime are somewhat different concerns.
> Doesn't mean thay cannot be fixed at the same time but it's a bit a
> separate.
Which reminds me... Somewhere else (maybe elsewhere in this thread? maybe
on a bug trac
Agreed with Antoine, strftime/strptime are somewhat different concerns.
Doesn't mean thay cannot be fixed at the same time but it's a bit a
separate.
I'm not sure this thread / discussion has reached critical mass yet,
meanwhile I was looking at what was involved and came up with this
half-b
MRAB wrote:
Maybe, also, strptime could support "%*f" to gobble as many digits as
are available.
The * would suggest that the number of digits is being
supplied as a parameter. Maybe "%?f".
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
ht
2014-12-11 22:00 GMT+01:00 MRAB :
>
> On 2014-12-11 18:33, Skip Montanaro wrote:
>>
>>
>> there are likely to be situations where the caller assumes it
>> generates a six-digit string. I did a little poking around. It seems
>> like "%N" isn't used.
>>
>> Could the number of digits be specified? Yo
On 2014-12-11 18:33, Skip Montanaro wrote:
On Thu, Dec 11, 2014 at 11:58 AM, Matthieu Bec wrote:
...or keep using "%f" if acceptable...
That might be a problem. While it will probably work most of the time,
there are likely to be situations where the caller assumes it
generates a six-digit st
Ethan Furman :
> On 12/11/2014 11:14 AM, Guido van Rossum wrote:
>> (I wouldn't be surprised if there wasn't -- while computer clocks
>> have a precision in nanoseconds, that doesn't mean they are that
>> *accurate* at all (even with ntpd running).
>
> The real-world use cases deal with getting th
On Thu, 11 Dec 2014 13:43:05 -0600
Skip Montanaro wrote:
> On Thu, Dec 11, 2014 at 1:23 PM, Antoine Pitrou wrote:
> > I think strftime / strptime support is a low-priority concern on this
> > topic, and can probably be discussed independently of the core
> > nanosecond support.
>
> Might be low-
On Thu, Dec 11, 2014 at 1:23 PM, Antoine Pitrou wrote:
> I think strftime / strptime support is a low-priority concern on this
> topic, and can probably be discussed independently of the core
> nanosecond support.
Might be low-priority, but with %f support as a template, supporting
something to s
On 12/11/2014 11:14 AM, Guido van Rossum wrote:
>
> (I wouldn't be surprised if there wasn't -- while computer clocks have a
> precision in
> nanoseconds, that doesn't mean they are that *accurate* at all (even with
> ntpd running).
[reading issue]
The real-world use cases deal with getting thi
On 12/11/2014 11:23 AM, Antoine Pitrou wrote:
>
> I think strftime / strptime support is a low-priority concern on this
> topic, and can probably be discussed independently of the core
> nanosecond support.
Agreed.
--
~Ethan~
signature.asc
Description: OpenPGP digital signature
__
I think strftime / strptime support is a low-priority concern on this
topic, and can probably be discussed independently of the core
nanosecond support.
Regards
Antoine.
On Thu, 11 Dec 2014 11:14:27 -0800
Guido van Rossum wrote:
> Another issue to consider here is that parsing and printing sh
Another issue to consider here is that parsing and printing should be
symmetrical. The %f format gobbles up exactly 6 digits.
Finally, strptime and strftime are not invented by Python, the same
functions with (mostly) the same format characters are defined by other
languages. Is there not a single
On Thu, Dec 11, 2014 at 11:58 AM, Matthieu Bec wrote:
> ...or keep using "%f" if acceptable...
That might be a problem. While it will probably work most of the time,
there are likely to be situations where the caller assumes it
generates a six-digit string. I did a little poking around. It seems
Thanks Stephen elaborating on the process.
and apologies, I was dismissing the last point only half jokingly.
I read the comment for strftime / strptime in the report as meant to
remember to implement it. It seems picking a new format letter (or keep
using "%f" if acceptable) that would accept
mdcb808 writes:
> These are typically discussed on this list or using the bug
> tracker?
I think this discussion belongs on python-dev because the requirement
is clear, but a full specification involves backward compatibility
with older interfaces, and clearly different people place different
v
On 12/10/14 7:33 AM, Nick Coghlan wrote:
On 10 December 2014 at 16:31, Matthieu Bec wrote:
newbie first post on this list, if what follows is of context ...
Hi all,
I'm struggling with issue per the subject, read different threads and issue
http://bugs.python.org/issue15443 that started 2012
On 10 December 2014 at 16:31, Matthieu Bec wrote:
>
> newbie first post on this list, if what follows is of context ...
>
> Hi all,
>
> I'm struggling with issue per the subject, read different threads and issue
> http://bugs.python.org/issue15443 that started 2012 still opened as of
> today.
>
>
newbie first post on this list, if what follows is of context ...
Hi all,
I'm struggling with issue per the subject, read different threads and
issue http://bugs.python.org/issue15443 that started 2012 still opened
as of today.
Isn't there a legitimate case for nanosecond support? it's all
It can't be *that* easy. DST never is... For one, the dst flag is two
bits -- it can be on, off, or undefined. Also it should probably only
apply when a tzinfo is present. I don't recall that pickling ever was
the reason, but it could have been the size of the in-memory
representation (for reasons
On Wed, Jul 25, 2012 at 9:11 PM, Christian Heimes wrote:
> Am 25.07.2012 14:11, schrieb Nick Coghlan:
>> 1. For the reasons presented, I think it's worth attempting to define
>> a common API that is based on datetime, but is tailored towards high
>> precision time operations (at least using a diff
Hi all again,
I've been quite busy these days and I collected all the suggestions
about the proposal. Here is a small summary:
Christian Heimes:
two numbers:
Julian Day Number (Rata Die) 32 bit signed integer
nanoseconds in a day 64 bit signed or unsigned integer
pro:
Am 25.07.2012 16:38, schrieb Guido van Rossum:
> Beware, people requesting dates BC rarely know what they are asking
> for. (E.g. Jesus wasn't born on 12/25/0001.) The calendrical
> ambiguities are such that representing dates that far in the past is
> better left to a specialized class. Read the o
1. For the reasons presented, I think it's worth attempting to define
a common API that is based on datetime, but is tailored towards high
precision time operations (at least using a different internal
representation, perhaps supporting TAI).
IIUC, the concern is about the DB-API, which does sor
On Wed, Jul 25, 2012 at 7:11 AM, Christian Heimes wrote:
> Am 25.07.2012 14:11, schrieb Nick Coghlan:
>> 1. For the reasons presented, I think it's worth attempting to define
>> a common API that is based on datetime, but is tailored towards high
>> precision time operations (at least using a diff
Christian Heimes wrote:
>
> days
>
> 32bit signed integer
>
> numbers of days since Jan 1, 1 AD in proleptic Gregorian calendar (aka
> modern civil calendar). That's Rata Die minus one day since it defines
> Jan 1, 1 AD as day 1. This allows days between year 5.8 Mio in the past
> and 5.8 M
Am 25.07.2012 14:11, schrieb Nick Coghlan:
> 1. For the reasons presented, I think it's worth attempting to define
> a common API that is based on datetime, but is tailored towards high
> precision time operations (at least using a different internal
> representation, perhaps supporting TAI).
This
Am 25.07.2012 13:48, schrieb Antoine Pitrou:
>> I'd vote for two separate numbers, the first similar to JDN (Julian Day
>> Number [1]), the second for nanoseconds per day. 3600 * 100 fit
>> nicely into an unsigned 32bit int.
>
> But 24 * 3600 * 1e9 doesn't. Perhaps I didn't understand your pro
On Wed, Jul 25, 2012 at 7:24 PM, Christian Heimes wrote:
> Am 25.07.2012 03:46, schrieb Guido van Rossum:
> I'd vote for two separate numbers, the first similar to JDN (Julian Day
> Number [1]), the second for nanoseconds per day. 3600 * 100 fit
> nicely into an unsigned 32bit int. This approa
On Wed, 25 Jul 2012 11:24:14 +0200
Christian Heimes wrote:
> Am 25.07.2012 03:46, schrieb Guido van Rossum:
> > First you will have to show how you'd have to code this *without*
> > nanosecond precision in datetime and how tedious that is. (I expect
> > that representing the timestamp as a long in
Am 25.07.2012 03:46, schrieb Guido van Rossum:
> First you will have to show how you'd have to code this *without*
> nanosecond precision in datetime and how tedious that is. (I expect
> that representing the timestamp as a long integer expressing a posix
> timestamp times a billion would be very r
On 07/24/2012 08:47 PM, Guido van Rossum wrote:
>
> So what functionality specifically do you require? You speak in
> generalities but I need specifics.
The ability of thinking datetime.datetime as a flexible class that can
give you the representation you need when you need. To be more specific
th
On Tue, Jul 24, 2012 at 8:25 PM, Vincenzo Ampolo
wrote:
> On 07/24/2012 06:46 PM, Guido van Rossum wrote:
>>
>> You're welcome.
>
> Hi Guido,
>
> I'm glad you spent your time reading my mail. I would have never
> imagined that my mail could come to your attention.
Stop brownnosing already. :-) If
On 07/24/2012 06:46 PM, Guido van Rossum wrote:
>
> You're welcome.
Hi Guido,
I'm glad you spent your time reading my mail. I would have never
imagined that my mail could come to your attention.
> Have you read PEP 410 and my rejection of it
> (http://mail.python.org/pipermail/python-dev/2012-F
On Tue, Jul 24, 2012 at 9:46 PM, Guido van Rossum wrote:
> I didn't read the entire bug, but it mentioned something about storing
> datetimes in databases. Do databases support nanosecond precision?
>
MS SQL Server 2008 R2 has the datetime2 data type which supports 100
nanosecond (.1 microsecond
On Tue, Jul 24, 2012 at 5:58 PM, Vincenzo Ampolo
wrote:
> Hi all,
>
> This is the first time I write to this list so thank you for considering
> this message (if you will) :)
You're welcome.
> I know that this has been debated many times but until now there was no
> a real use case. If you look
Hi all,
This is the first time I write to this list so thank you for considering
this message (if you will) :)
I know that this has been debated many times but until now there was no
a real use case. If you look on google about "python datetime
nanosecond" you can find more than 141k answer about
49 matches
Mail list logo
