durations are usually hours or days, I would generally want to display
the duration in a format such as "dd-hh:mm:ss"
d = datetime_diff.days
h, rem = divmod( datetime_diff.seconds, 3600 )
m, s = divmod( rem, 60 )
print( f'{d:02}-{h:02}:{m:02}:{s:02}' )
ram@zedat.fu-berlin.de (Stefan Ram) writes:
d = datetime_diff.days
h, rem = divmod( datetime_diff.seconds, 3600 )
m, s = divmod( rem, 60 )
print( f'{d:02}-{h:02}:{m:02}:{s:02}' )
If the default formatting is acceptable to you, you can also
print the datetime_diff in a shorter way:
main.py
from datetime import datetime
format = '%Y-%m-%dT%H:%M:%S%z'
datetime_0 = datetime.strptime( '2023-03-27T14:00:52+01:00', format ) datetime_1 = datetime.strptime( '2023-03-27T14:27:23+01:00', format )
print( datetime_1 - datetime_0 )
sys.stdout
0:26:31
. Days will also be shown if greater than zero.
I need to deal with what I call a 'period', which is a span of time
limited by two dates, start and end. The period has a 'duration',
which is the elapsed time between start and end. The duration is
essentially a number of seconds, but in my context, because the
durations are usually hours or days, I would generally want to display
the duration in a format such as "dd-hh:mm:ss"
Hi,
I have been around long enough to know that, due to time-zones, daylight saving and whatnot, time-related stuff is complicated. So even if I
think something connected with time should exist, there may well be a
very good reason why it does not.
My problem:
I need to deal with what I call a 'period', which is a span of time
limited by two dates, start and end. The period has a 'duration',
which is the elapsed time between start and end. The duration is
essentially a number of seconds, but in my context, because the
durations are usually hours or days, I would generally want to display
the duration in a format such as "dd-hh:mm:ss"
My (possibly ill-founded) expectation:
There is a standard class which encapsulates this sort of functionality.
My (possibly insufficiently researched) conclusion:
Such a standard class does not exist.
What is at fault here? My expectation or my conclusion?
Cheers,
Loris
On Mon, 27 Mar 2023 15:00:52 +0200, Loris Bennett wrote:
I need to deal with what I call a 'period', which is a span of time
limited by two dates, start and end. The period has a 'duration',
which is the elapsed time between start and end. The duration is
essentially a number of seconds, but in my context, because the
durations are usually hours or days, I would generally want to display
the duration in a format such as "dd-hh:mm:ss"
https://www.programiz.com/python-programming/datetime
Scroll down to timedelta. If '14 days, 13:55:39' isn't good enough you'll have to format it yourself.
On 3/27/2023 11:34 AM, rbowman wrote:
On Mon, 27 Mar 2023 15:00:52 +0200, Loris Bennett wrote:
I need to deal with what I call a 'period', which is a span of timehttps://www.programiz.com/python-programming/datetime
limited by two dates, start and end. The period has a 'duration',
which is the elapsed time between start and end. The duration is
essentially a number of seconds, but in my context, because the
durations are usually hours or days, I would generally want to display >>> the duration in a format such as "dd-hh:mm:ss"
Scroll down to timedelta. If '14 days, 13:55:39' isn't good enough
you'll
have to format it yourself.
I second this. timedelta should give the OP exactly what he's talking
about.
No, it doesn't. I already know about timedelta. I must have explained
the issue badly, because everyone seems to be fixating on the
formatting, which is not a problem and is incidental to what I am really >interested in, namely:
1. Is there a standard class for a 'period', i.e. length of time
specified by a start point and an end point? The start and end
points could obviously be datetimes and the difference a timedelta,
but the period '2022-03-01 00:00 to 2022-03-02 00:00' would be
different to '2023-03-01 00:00 to 2023-03-02 00:00' even if the
*duration* of both periods is the same.
2. If such a standard class doesn't exist, why does it not exist?
On Tue, 28 Mar 2023 08:14:55 +0200, "Loris Bennett" <loris.bennett@fu-berlin.de> declaimed the following:
No, it doesn't. I already know about timedelta. I must have explained
the issue badly, because everyone seems to be fixating on the
formatting, which is not a problem and is incidental to what I am really >>interested in, namely:
1. Is there a standard class for a 'period', i.e. length of time
specified by a start point and an end point? The start and end
points could obviously be datetimes and the difference a timedelta,
but the period '2022-03-01 00:00 to 2022-03-02 00:00' would be
different to '2023-03-01 00:00 to 2023-03-02 00:00' even if the
*duration* of both periods is the same.
2. If such a standard class doesn't exist, why does it not exist?
So far, you seem to be the only person who has ever asked for a single entity incorporating an EPOCH (datetime.datetime) + a DURATION (datetime.timedelta). You are asking for two durations of the same length
to be considered different if they were computed from different "zero" references (epochs).
I don't think I've ever encountered an application
that doesn't use a single epoch (possibly per run) with all internal computations using a timedelta FROM THAT EPOCH! (The exception may have
been computing star atlases during the conversion from B1900 to J2000 reference frames.)
But even if I have a single epoch, January 2022 is obviously different
to January 2023, even thought the duration might be the same. I am just surprised that there is no standard Period class, with which I could
create objects and then be able to sort, check for identity, equality of length, amount of overlap, etc. I suppose people just use a datetime.datetime pair, as I have been doing so far, and tack on just
the specific bit of functionality they need.
No, it doesn't. I already know about timedelta. I must have explained
the issue badly, because everyone seems to be fixating on the
formatting, which is not a problem and is incidental to what I am really interested in, namely:
1. Is there a standard class for a 'period', i.e. length of time
specified by a start point and an end point? The start and end
points could obviously be datetimes and the difference a timedelta,
but the period '2022-03-01 00:00 to 2022-03-02 00:00' would be
different to '2023-03-01 00:00 to 2023-03-02 00:00' even if the
*duration* of both periods is the same.
So far, you seem to be the only person who has ever asked for a
single entity incorporating an EPOCH (datetime.datetime) + a
DURATION (datetime.timedelta).
If there's no obvious common definition for what a class is supposed
to do, then there can't really be a standard one...
On 3/28/2023 12:13 PM, Grant Edwards wrote:
On 2023-03-28, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
So far, you seem to be the only person who has ever asked for a
single entity incorporating an EPOCH (datetime.datetime) + a
DURATION (datetime.timedelta).
It seems to me that tuple of two timdate objects (start,end) is the
more obvious representation, but it's six of one and a horse of the
same color.
If one really needs it to be a class, then it woulnd't be much more
than a dozen or two lines of code...
I think it would be more than that. The OP said
On 2023-03-28, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
So far, you seem to be the only person who has ever asked for a
single entity incorporating an EPOCH (datetime.datetime) + a
DURATION (datetime.timedelta).
It seems to me that tuple of two timdate objects (start,end) is the
more obvious representation, but it's six of one and a horse of the
same color.
If one really needs it to be a class, then it woulnd't be much more
than a dozen or two lines of code...
But even if I have a single epoch, January 2022 is obviously different1. Is there a standard class for a 'period', i.e. length of time
specified by a start point and an end point? The start and end
points could obviously be datetimes and the difference a timedelta,
but the period '2022-03-01 00:00 to 2022-03-02 00:00' would be
different to '2023-03-01 00:00 to 2023-03-02 00:00' even if the
*duration* of both periods is the same.
to January 2023, even thought the duration might be the same. I am just surprised that there is no standard Period class, with which I could
create objects and then be able to sort, check for identity, equality of length, amount of overlap, etc. I suppose people just use a datetime.datetime pair, as I have been doing so far, and tack on just
the specific bit of functionality they need.
So far, you seem to be the only person who has ever asked for a
single
entity incorporating an EPOCH (datetime.datetime) + a DURATION >(datetime.timedelta).
On 28Mar2023 08:05, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
So far, you seem to be the only person who has ever asked for
a single
entity incorporating an EPOCH (datetime.datetime) + a DURATION >>(datetime.timedelta).
But not the only person to want one. I've got a timeseries data format
where (within a file) time slots are represented as a seconds offset,
and the file has an associated epoch starting point. Dual to that is
that a timeslot has an offset from the file start, and that is
effectively a (file-epoch, duration) notion.
I've got plenty of code using that which passes around UNIX timestamp start/stop pairs. Various conversions happen to select the appropriate
file (this keeps the files of bounded size while supporting an
unbounded time range).
Even a UNIX timestamp has an implied epoch, and therefore kind of
represents that epoch plus the timestamp as a duration.
I'm not sure I understand Loris' other requirements though. It might
be hard to write a general thing which was also still useful.
I am glad to hear that I am not alone :-) However, my use-case is fairly trivial, indeed less complicated than yours. So, in truth I don't
really need a Period class. I just thought it might be a sufficiently generic itch that someone else with a more complicated use-case could
have already scratched. After all, that the datetime classes exist,
even though I only use a tiny part of the total functionality.
Cheers,
Loris
I do in fact have a `TimePartition` in my timeseries module; it
presently doesn't do comparisons because I'm not comparing them - I'm
just using them as slices into the timeseries data on the whole.
https://github.com/cameron-simpson/css/blob/0ade6d191833b87cab8826d7ecaee4d114992c45/lib/python/cs/timeseries.py#L2163
I am glad to hear that I am not alone :-) However, my use-case is fairly >trivial, indeed less complicated than yours. So, in truth I don't
really need a Period class. I just thought it might be a sufficiently >generic itch that someone else with a more complicated use-case could
have already scratched.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 65:26:00 |
| Calls: | 6,712 |
| Files: | 12,244 |
| Messages: | 5,356,205 |