On Thu, May 17, 2018 at 9:49 AM, Chris Barker via Python-ideas
wrote:
> On Tue, May 15, 2018 at 11:21 AM, Rob Speer wrote:
>>
>>
>> I'm sure that the issue of "what do you call the leap second itself" is
>> not the problem that Chris Barker is referring to. The problem with leap
>> seconds is tha
On Thu, May 17, 2018 at 7:12 PM Wes Turner wrote:
> AstroPy solves for leap seconds [1][2] according to the IAU ERFA (SOFA)
> library [3] and the IERS-B and IERS-A tables [4]. IERS-B tables ship with
> AstroPy. The latest IERS-A tables ("from 1973 though one year into the
> future") auto-download
https://en.wikipedia.org/wiki/Leap_second :
> Insertion of each UTC leap second is usually decided about six months in
advance by the International Earth Rotation and Reference Systems Service
(IERS), when needed to ensure that the difference between the UTC and UT1
readings will never exceed 0.9
AstroPy solves for leap seconds [1][2] according to the IAU ERFA (SOFA)
library [3] and the IERS-B and IERS-A tables [4]. IERS-B tables ship with
AstroPy. The latest IERS-A tables ("from 1973 though one year into the
future") auto-download on first use [5].
[1] http://docs.astropy.org/en/stable/ti
On Thu, May 17, 2018 at 3:13 PM Tim Peters wrote:
> [Chris Barker]
> > Does that support the other way -- or do we never lose a leap second
> anyway?
> > (showing ignorance here)
>
> Alexander covered the Python part of this, ...
>
No, I did not. I did not realize that the question was about s
now we really have gotten OT...
But thanks! that was my question!
-CHB
Alexander covered the Python part of this, so I'll answer the possible
> higher-level question: we haven't yet needed a "negative" leap
> second, and it's considered unlikely (but not impossible) that we ever
> will. That'
[Chris Barker]
> Does that support the other way -- or do we never lose a leap second anyway?
> (showing ignorance here)
Alexander covered the Python part of this, so I'll answer the possible
higher-level question: we haven't yet needed a "negative" leap
second, and it's considered unlikely (but
On Thu, May 17, 2018 at 2:51 PM Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
>
> TAI | UTC
> -+
> 2016-12-31T23:59:35 | 2016-12-31T23:59:59
> 2016-12-31T23:59:36 | 2016-12-31T23:59:60
> 2016-12-31T23:59:37 | 2017-01-01T00
On Thu, May 17, 2018 at 1:33 PM Chris Barker wrote:
>
> On Thu, May 17, 2018 at 10:14 AM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
>> [...] Since the implementation of PEP 495, it is
>> possible to represent the 23:59:60 as 23:59:59 with the "fold" bit set.
Of
>> course, the
On Thu, May 17, 2018 at 10:14 AM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
> > The other issue with leap-seconds is that python's datetime doesn't
> support them :-)
>
> That's not entirely true. Since the implementation of PEP 495, it is
> possible to represent the 23:59:60
On Thu, May 17, 2018 at 12:56 PM Chris Barker via Python-ideas <
python-ideas@python.org> wrote:
> The other issue with leap-seconds is that python's datetime doesn't
support them :-)
That's not entirely true. Since the implementation of PEP 495, it is
possible to represent the 23:59:60 as 23:59
On Tue, May 15, 2018 at 11:21 AM, Rob Speer wrote:
>
> I'm sure that the issue of "what do you call the leap second itself" is
> not the problem that Chris Barker is referring to. The problem with leap
> seconds is that they create unpredictable differences between UTC and real
> elapsed time.
>
On Mon, 14 May 2018 at 12:17 Chris Angelico wrote:
> On Tue, May 15, 2018 at 2:05 AM, Chris Barker via Python-ideas
> wrote:
> > But my question is whether high precision timedeltas belongs with
> "calendar
> > time" at all.
> >
> > What with UTC and leap seconds, and all that, it gets pretty ug
>From "[Python-Dev] PEP 564: Add new time functions with nanosecond
resolution" (2017-10-16 hh:mm ss[...] -Z)
https://groups.google.com/forum/m/#!topic/dev-python/lLJuW_asYa0 :
> Maybe that's why we haven't found any CTCs (closed timelike curves) yet.
>
> Aligning simulation data in context to oth
Chris is certainly right. A program that deals with femtosecond intervals
should almost surely start by defining a "start of experiment" epoch where
microseconds are fine. Then within that epoch, events should be monotonic
integers for when measured or calculated times are marked.
I can easily see
>
> UTC and leap seconds aren't a problem.
Of course they are a problem— why else would they not be implemented
in datetime?
But my point if that given datetimestamp or calculation could be off
by a second or so depending on whether and how leap seconds are
implemented.
It just doesn’t seem like
On Tue, May 15, 2018 at 2:05 AM, Chris Barker via Python-ideas
wrote:
> But my question is whether high precision timedeltas belongs with "calendar
> time" at all.
>
> What with UTC and leap seconds, and all that, it gets pretty ugly, when down
> to the second or sub-second, what a given datetime
On Thu, May 10, 2018 at 6:13 PM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
> > Is there interest in a PEP for extending time, datetime / timedelta for
> arbitrary or extended precision fractional seconds?
>
> Having seen the utter disaster that similar ideas brought to numpy, I
You don't mention the option of allowing time.microseconds to be a
float, and I was curious about that since if it did work, then that
might be a relatively smooth extension of the current API. The highest
value you'd store in the microseconds field is 1e6, and at values
around 1e6, double-precisio
In fairness, Pandas, datetime64, and Arrow are really the same thing. I
don't know about Pendulum or Delorean. A common standard would be great, or
at least strong interoperability. I'm sure the authors of those projects
would want that... Arrow is entirely about interoperability, after all.
On Th
On 05/10/2018 10:30 AM, Ed Page wrote:
Alternatives
- My company create our own datetime library
- Continued fracturing of time ... ecosystem (datetime, arrow, pendulum,
delorean, datetime64, pandas.Timestamp
Or, team up with one of those (if you can).
--
~Ethan~
__
> Is there interest in a PEP for extending time, datetime / timedelta for
arbitrary or extended precision fractional seconds?
Having seen the utter disaster that similar ideas brought to numpy, I would
say: no.
On the other hand, nanoseconds are slowly making their way to the stdlib
and to add na
I have to agree with David that this seems too specialized to make room for
in the stdlib.
On Thu, May 10, 2018, 15:16 David Mertz wrote:
> This feels specialized enough to belong in a third party library. If that
> library can behave as transparently as possible interacting with Python
> dateti
This feels specialized enough to belong in a third party library. If that
library can behave as transparently as possible interacting with Python
datetime, so much the better. But the need is niche enough I don't think it
belongs in standard library.
... this as someone who actually worked in a la
24 matches
Mail list logo
