Dennis Lee Bieber writes:
> On Tue, 19 Apr 2022 15:51:09 +0200, "Loris Bennett"
> declaimed the following:
>
>>If I am merely trying to represent part a very large number of seconds
>>as a number of years, 365 days per year does not seem that controversial
>
> The Explanatory Supplement to
Random832 writes:
> On Tue, Apr 19, 2022, at 07:11, Loris Bennett wrote:
>> I now realise that timedelta is not really what I need. I am
>> interested solely in pure periods, i.e. numbers of seconds, that I
>> can convert back and forth from a format such as
>
> A timedelta *is* a pure period.
t; et.normalize(et.localize(datetime.datetime(2022,3,12,12,0,0)) +
>>> datetime.timedelta(days=1))
datetime.datetime(2022, 3, 13, 13, 0, tzinfo=)
you can see here that 2022-03-12T12:00-0500 + timedelta(days=1) correctly
becomes 2022-03-13T13:00-0400, 24 hours later.
As far as I know, Python doesn&#x
On 2022-04-19, Barry wrote:
>> On 19 Apr 2022, at 19:38, Dennis Lee Bieber wrote:
>> *I /think/ this is the year used for leap-day calculations, and
>> why some leap centuries are skipped as it is really less than a
>> quarter day per year, so eventually one gets to over-correcting
> On 19 Apr 2022, at 19:38, Dennis Lee Bieber wrote:
>
> *I /think/ this is the year used for leap-day calculations, and why some
> leap centuries are skipped as it is really less than a quarter day per
> year, so eventually one gets to over-correcting by a day.
Leap century is skip unless
On 2022-04-19 19:23, Dennis Lee Bieber wrote:
On Tue, 19 Apr 2022 15:51:09 +0200, "Loris Bennett"
declaimed the following:
If I am merely trying to represent part a very large number of seconds
as a number of years, 365 days per year does not seem that controversial
The Explanatory S
On Tue, 19 Apr 2022 15:51:09 +0200, "Loris Bennett"
declaimed the following:
>If I am merely trying to represent part a very large number of seconds
>as a number of years, 365 days per year does not seem that controversial
The Explanatory Supplement to the Astronomical Almanac (table 15.
On Wed, 20 Apr 2022 at 02:16, Loris Bennett wrote:
> I now realise that timedelta is not really what I need. I am interested
> solely in pure periods, i.e. numbers of seconds, that I can convert back
> and forth from a format such as
>
> 11-22::44:55
>
> (These are the lengths of time a job has
Jon Ribbens writes:
> On 2022-04-19, Loris Bennett wrote:
>> If I am merely trying to represent part a very large number of seconds
>> as a number of years, 365 days per year does not seem that controversial
>> to me. Obviously there are issues if you expect all periods of an
>> integer number
On 2022-04-19, Loris Bennett wrote:
> If I am merely trying to represent part a very large number of seconds
> as a number of years, 365 days per year does not seem that controversial
> to me. Obviously there are issues if you expect all periods of an
> integer number of years which start on a gi
On 2022-04-19, Loris Bennett wrote:
> Jon Ribbens writes:
>> On 2022-04-19, Loris Bennett wrote:
>>> I now realise that timedelta is not really what I need. I am interested
>>> solely in pure periods, i.e. numbers of seconds,
>>
>> That's exactly what timedelta is.
>>
>>> that I can convert bac
Jon Ribbens writes:
> On 2022-04-19, Loris Bennett wrote:
>> I now realise that timedelta is not really what I need. I am interested
>> solely in pure periods, i.e. numbers of seconds,
>
> That's exactly what timedelta is.
>
>> that I can convert back and forth from a format such as
>>
>> 11-
On 2022-04-19, Loris Bennett wrote:
> I now realise that timedelta is not really what I need. I am interested
> solely in pure periods, i.e. numbers of seconds,
That's exactly what timedelta is.
> that I can convert back and forth from a format such as
>
> 11-22::44:55
I don't recognise that
Jon Ribbens writes:
> On 2022-04-19, Loris Bennett wrote:
>> Jon Ribbens writes:
>>> On 2022-04-19, Loris Bennett wrote:
I now realise that timedelta is not really what I need. I am interested
solely in pure periods, i.e. numbers of seconds,
>>>
>>> That's exactly what timedelta is.
> >>
>> >> >>> import datetime, zoneinfo
>> >> >>> LOS_ANGELES = zoneinfo.ZoneInfo('America/Los_Angeles')
>> >> >>> UTC = zoneinfo.ZoneInfo('UTC')
>> >> >>> d = datetime.datetime(2020, 1
;> >>> LOS_ANGELES = zoneinfo.ZoneInfo('America/Los_Angeles')
> >> >>> UTC = zoneinfo.ZoneInfo('UTC')
> >> >>> d = datetime.datetime(2020, 10, 31, 12, tzinfo=LOS_ANGELES)
> >> >>> print(d)
> >> 20
On 2022-04-16, Dennis Lee Bieber wrote:
> On Sat, 16 Apr 2022 20:35:22 - (UTC), Jon Ribbens
> declaimed the following:
>>I can categorically guarantee you it is not. But let's put it a
>>different way, if you like, if I want to add 24 hours, i.e. 86,400
>>seconds (or indeed any other fixed tim
On Sun, 17 Apr 2022 at 08:37, Dennis Lee Bieber wrote:
> And proposals to make
> DST permanent year round -- so "noon" (1200hrs) is not "noon" (sun at
> zenith) pretty much anywhere.
>
Noon isn't precisely zenith anyway, for several reasons:
1) Time zones synchronize their clocks on the mean noo
On Sat, 16 Apr 2022 20:35:22 - (UTC), Jon Ribbens
declaimed the following:
>I can categorically guarantee you it is not. But let's put it a
>different way, if you like, if I want to add 24 hours, i.e. 86,400
>seconds (or indeed any other fixed time period), to a timezone-aware
>datetime in Py
, zoneinfo
>> >>> LOS_ANGELES = zoneinfo.ZoneInfo('America/Los_Angeles')
>> >>> UTC = zoneinfo.ZoneInfo('UTC')
>> >>> d = datetime.datetime(2020, 10, 31, 12, tzinfo=LOS_ANGELES)
>> >>> print(d)
>> 20
On Sun, 17 Apr 2022 at 05:38, Peter J. Holzer wrote:
>
> On 2022-04-17 02:46:38 +1000, Chris Angelico wrote:
> > On Sun, 17 Apr 2022 at 02:45, Peter J. Holzer wrote:
> > > For adding a datetime and timedelta I think the answer is clear.
> > > But subtracting two datetimes is ambiguous.
> > >
> >
On 2022-04-17 02:46:38 +1000, Chris Angelico wrote:
> On Sun, 17 Apr 2022 at 02:45, Peter J. Holzer wrote:
> > For adding a datetime and timedelta I think the answer is clear.
> > But subtracting two datetimes is ambiguous.
> >
>
> But if the difference between two datetimes is a timedelta, then
er
post).
>> > Python missed the switch to DST here, the timezone is wrong.
>>
>> Because you didn't let it use any timezone information.
>
> I used astimezone() and it returned something something that Python
> calls "timezone aware" containing time zo
On Sun, 17 Apr 2022 at 03:52, Peter J. Holzer wrote:
>
> On 2022-04-17 02:46:38 +1000, Chris Angelico wrote:
> > On Sun, 17 Apr 2022 at 02:45, Peter J. Holzer wrote:
> > > On 2022-04-17 02:14:44 +1000, Chris Angelico wrote:
> > > > So which one is it? Which one do you get when you add days=7 to a
On 2022-04-17 02:46:38 +1000, Chris Angelico wrote:
> On Sun, 17 Apr 2022 at 02:45, Peter J. Holzer wrote:
> > On 2022-04-17 02:14:44 +1000, Chris Angelico wrote:
> > > So which one is it? Which one do you get when you add days=7 to a
> > > datetime?
> >
> > For adding a datetime and timedelta I
On Sun, 17 Apr 2022 at 02:45, Peter J. Holzer wrote:
>
> On 2022-04-17 02:14:44 +1000, Chris Angelico wrote:
> > On Sun, 17 Apr 2022 at 02:03, Peter J. Holzer wrote:
> > > On the contrary. When a datetime is timezone aware, it must use that
> > > timezone's rules. Adding one day to a datetime jus
On 2022-04-17 02:14:44 +1000, Chris Angelico wrote:
> On Sun, 17 Apr 2022 at 02:03, Peter J. Holzer wrote:
> > On the contrary. When a datetime is timezone aware, it must use that
> > timezone's rules. Adding one day to a datetime just before a DST switch
> > must add 23 or 25 hours, not 24. This
in the real world.
>
> > but d1 is 25 hours later
> > than 'd'. If we do the calculations in UTC instead, it works correctly:
> >
> > >>> print((d.astimezone(UTC) +
> > datetime.timedelta(days=1)).astimezone(LOS_ANGELES))
> >
gt;>> UTC = zoneinfo.ZoneInfo('UTC')
> >>> d = datetime.datetime(2020, 10, 31, 12, tzinfo=LOS_ANGELES)
> >>> print(d)
> 2020-10-31 12:00:00-07:00
> >>> d1 = d + datetime.timedelta(days=1)
> >>> print(d1)
>
>
> > I'd call that a bug, not a feature:
>
> It's the only possible way of implementing it,
It's definitely not the only possible way of implementing it. PostgreSQL
for examply has implemented it correctly. I'm quite sure some other
programming languages have, to
HEM".
Suppose we do this:
>>> import datetime, zoneinfo
>>> LOS_ANGELES = zoneinfo.ZoneInfo('America/Los_Angeles')
>>> UTC = zoneinfo.ZoneInfo('UTC')
>>> d = datetime.datetime(2020, 10, 31, 12, tzinfo=LOS_ANGELES)
>>> pri
of implementing it, so it can't be a bug.
The documentation could be better though.
>>>> from datetime import datetime, timedelta
>>>> t0 = datetime.fromisoformat("2022-03-26T12:00").astimezone()
>>>> t0
> datetime.datetime(2022, 3, 26, 12, 0,
&g
an undocumented feature of timedelta that by 'day' it means '86400
> seconds'.
I'd call that a bug, not a feature:
>>> from datetime import datetime, timedelta
>>> t0 = datetime.fromisoformat("2022-03-26T12:00").astimezone()
>>>
On 2022-04-14, MRAB wrote:
> On 2022-04-14 16:22, Jon Ribbens via Python-list wrote:
>> On 2022-04-14, Paul Bryan wrote:
>>> I think because minutes and hours can easily be composed by multiplying
>>> seconds. days is separate because you cannot compose days from seconds;
>>> leap seconds are app
On Fri, 15 Apr 2022 at 00:54, Loris Bennett wrote:
>
> Hi,
>
> With Python 3.9.2 I get
>
> $ import datetime
> $ s = "1-00:01:01"
> $ t = datetime.datetime.strptime(s, "%d-%H:%M:%S")
> $ d = datetime.timedelta(days=t.day, hours=t.hour, minu
On Fri, 15 Apr 2022 at 03:45, Marco Sulla wrote:
>
> On Thu, 14 Apr 2022 at 19:16, MRAB wrote:
> >
> > When you're working only with dates, timedelta not having a 'days'
> > attribute would be annoying, especially when you consider that a day is
> > usually 24 hours, but sometimes 23 or 25 hours
On Thu, 14 Apr 2022 at 19:16, MRAB wrote:
>
> When you're working only with dates, timedelta not having a 'days'
> attribute would be annoying, especially when you consider that a day is
> usually 24 hours, but sometimes 23 or 25 hours (DST).
I agree. Furthermore, timedelta is, well, a time delta
On 2022-04-14 16:22, Jon Ribbens via Python-list wrote:
On 2022-04-14, Paul Bryan wrote:
I think because minutes and hours can easily be composed by multiplying
seconds. days is separate because you cannot compose days from seconds;
leap seconds are applied to days at various times, due to
irre
On 2022-04-14, Paul Bryan wrote:
> I think because minutes and hours can easily be composed by multiplying
> seconds. days is separate because you cannot compose days from seconds;
> leap seconds are applied to days at various times, due to
> irregularities in the Earth's rotation.
That's an argu
in the Earth's rotation.
On Thu, 2022-04-14 at 15:38 +0200, Loris Bennett wrote:
"Loris Bennett" writes:
Hi,
With Python 3.9.2 I get
$ import datetime
$ s = "1-00:01:01"
$ t = datetime.datetime.strptime(s, "%d-%H:%M:%S")
$ d = datetime.timedelt
wrote:
> "Loris Bennett" writes:
>
> > Hi,
> >
> > With Python 3.9.2 I get
> >
> > $ import datetime
> > $ s = "1-00:01:01"
> > $ t = datetime.datetime.strptime(s, "%d-%H:%M:%S")
> > $ d = datetime.t
"Loris Bennett" writes:
> Hi,
>
> With Python 3.9.2 I get
>
> $ import datetime
> $ s = "1-00:01:01"
> $ t = datetime.datetime.strptime(s, "%d-%H:%M:%S")
> $ d = datetime.timedelta(days=t.day, hours=t.hour, minutes=t.minute,
> se
Hi,
With Python 3.9.2 I get
$ import datetime
$ s = "1-00:01:01"
$ t = datetime.datetime.strptime(s, "%d-%H:%M:%S")
$ d = datetime.timedelta(days=t.day, hours=t.hour, minutes=t.minute,
seconds=t.second)
$ d.days
1
$ d.seconds
61
$ d.minu
En Tue, 17 May 2011 07:44:08 -0300, Tsolmon Narantsogt
escribió:
I'm using datetime.timedelta and i have a problem
delta = 1 day, 2:30:00
hours = delta.days * 8
how to add 8 + 2:30:00
Just operate with it as it were a number. The timedelta class implements
all "sane&quo
Hi list
I'm using datetime.timedelta and i have a problem
delta = 1 day, 2:30:00
hours = delta.days * 8
how to add 8 + 2:30:00
Regards Tsolmon.
--
http://mail.python.org/mailman/listinfo/python-list
On Sun, May 15, 2011 at 11:50 PM, Chris Angelico wrote:
> On Mon, May 16, 2011 at 10:42 AM, Jorge Romero
> wrote:
> > Hi Pythonists,
> > I'm retrieving some time data from a MySQL database using Python's
> MySQLdb
> > library. Here's the situation, I got a time field on MySQL given in
> seconds,
On Mon, May 16, 2011 at 10:42 AM, Jorge Romero wrote:
> Hi Pythonists,
> I'm retrieving some time data from a MySQL database using Python's MySQLdb
> library. Here's the situation, I got a time field on MySQL given in seconds,
> I need it on HH:MM:SS format, so I'm SELECTING that field with SEC_TO
is:
query = "SELECT SEC_TO_TIME(SUM(seconds)) FROM table"
fetched = cursor.execute(query)
return fetched[0]
The result of the query is given to me as *datetime.timedelta *type, which
has an undesired print behavior for my purposes:
>>> query = "SELECT SEC_TO_TIME(SUM(seconds)) FR
> Try d // 2 ?
> It may be that v2.6 considers / as __truediv__ and not __div__.
Ah, right you are. Thanks...
Skip
--
http://mail.python.org/mailman/listinfo/python-list
On Sep 1, 7:28 pm, [EMAIL PROTECTED] wrote:
> Running from Subversion, I see confusing (to me) behavior related to
> division of datetime.timedelta objects by integers:
>
> % python
> Python 2.6a0 (trunk:57277:57280M, Aug 28 2007, 17:44:49)
> [GCC 4.0.1 (Apple Compute
Running from Subversion, I see confusing (to me) behavior related to
division of datetime.timedelta objects by integers:
% python
Python 2.6a0 (trunk:57277:57280M, Aug 28 2007, 17:44:49)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyr
Ant wrote:
> John Machin wrote:
> ...
> > 1. If that's what he wanted, it was a very peculiar way of asking. Do
> > you suspect that he needs to be shown how to conver 877.7... minutes
> > into hours, minutes and seconds???
>
> Chill dude, It wasn't an attack :-)
I didn't think it was.
>
> The d
John Machin wrote:
...
> 1. If that's what he wanted, it was a very peculiar way of asking. Do
> you suspect that he needs to be shown how to conver 877.7... minutes
> into hours, minutes and seconds???
Chill dude, It wasn't an attack :-)
The datetime class has hour, minute and second attributes
Ant wrote:
> John Machin wrote:
> > Lad wrote:
> > > Hello,
> > > what is the best /easest way how to get number of hours and minutes
> > > from a timedelta object?
> ...
> > >>> diff.days
> > 0
> > >>> diff.seconds
> > 52662
> > >>> diff.microseconds
> > 922000
> > >>> minutes = (diff.seconds +
John Machin wrote:
> Lad wrote:
> > Hello,
> > what is the best /easest way how to get number of hours and minutes
> > from a timedelta object?
...
> >>> diff.days
> 0
> >>> diff.seconds
> 52662
> >>> diff.microseconds
> 922000
> >>> minutes = (diff.seconds + diff.microseconds / 100.0) / 60.0
Lad wrote:
> Hello,
> what is the best /easest way how to get number of hours and minutes
> from a timedelta object?
> Let's say we have
> aa=datetime.datetime(2006, 7, 29, 16, 13, 56, 609000)
> bb=datetime.datetime(2006, 8, 3, 17, 59, 36, 46000)
> so
> c=bb-aa
>
Hello,
what is the best /easest way how to get number of hours and minutes
from a timedelta object?
Let's say we have
aa=datetime.datetime(2006, 7, 29, 16, 13, 56, 609000)
bb=datetime.datetime(2006, 8, 3, 17, 59, 36, 46000)
so
c=bb-aa
will be
datetime.timedelta(5, 6339, 437000)
I can easil
57 matches
Mail list logo
