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

--
This signature is currently under constuction.

"Loris Bennett" <loris.bennett@fu-berlin.de> writes:
>durations are usually hours or days, I would generally want to display
>the duration in a format such as "dd-hh:mm:ss"

Here is an attempt to do this in Python 3.9:

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 )

datetime_diff = datetime_1 - datetime_0

print( type( datetime_diff ))

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}' )

sys.stdout

<class 'datetime.timedelta'>
00-00:26:31

.

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.

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> 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.

Thanks for the examples, but I am not really interested in how to write
a bunch of code to do what I need, as I can already do that. I am
interested in whether there is a standard class for this and, if there is
not such a class, why this is the case.

Cheers,

Loris

--
This signature is currently under constuction.

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.

The Python standard library module datetime seems to be what you want. 
It has objects representing date/times, and deltatimes (i.e.,
durations).  These can be timezone aware or not as you wish.

Dr. Gary Herron
Professor of Computer Science
DigiPen Institute of Technology

On 3/27/23 6:00 AM, loris.bennett@fu-berlin.de wrote:
> 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 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 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.

I second this. timedelta should give the OP exactly what he's talking
about.

Thomas Passin <list1@tompassin.net> writes:

> 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 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.
>
> 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?

Cheers,

Loris

--
This signature is currently under constuction.

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.)

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> 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 thought I was asking for two periods of the same duration to be
considered different, if they have different starting points :-)

> 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.

--
This signature is currently under constuction.

On Tue, 28 Mar 2023 15:11:14 +0200, Loris Bennett wrote:

> 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.

It's called Unix time... Convert the seconds into whatever you want.

> 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.

Not that I know, within the constraints of the standard library.

However:

class CalendarPeriod:
def __init__(self, start, end):
self.start = start
self.end = end

?

For this to be *useful* more needs need to be explained. Until then - YAGNI.

Karsten

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...

--
Grant

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

"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."

A class could be devised to have methods to do those things, but it
would take some thought to be sure if they all made sense. Take
sorting, for example. Are two "Periods" really comparable? Can we have
complete ordering here? "Identity" too would have to be carefully
defined, and then a __eq__ method could be implemented. And so on.

It would take more than 10 or 20 lines, I would think. But the hard
work of figuring out exactly what is wanted and what even makes sense to
implement needs to be done first.

On 2023-03-28, Thomas Passin <list1@tompassin.net> wrote:
> 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

You're right. I had forgotten about a few of the operations mentioned,
so it might take a bit more than a couple dozen line, but not _that_
much more. The hard part would be defining those operations, and as
the OP says, it doesn't seem to me like there is an obvious definition
for many of them.

If there's no obvious common definition for what a class is supposed
to do, then there can't really be a standard one...

--
Grant

Grant Edwards <grant.b.edwards@gmail.com> writes:
>If there's no obvious common definition for what a class is supposed
>to do, then there can't really be a standard one...

The C++ library boost has "boost::locale::date_time_duration".
It has few public methods:

|This class represents a period: a pair of two date_time objects.
|It is generally used as syntactic sugar to calculate
|difference between two dates.

. In Python, the Django scheduler has "periods.py":

|This class represents a period of time. It can return a set
|of occurrences. based on its events, and its time period
|(start and end).

.

>>> 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.
>>>
> 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.

The request for a "standard class" has probably been answered.

Please give a use-case example to help outline the problem to be solved...

eg if the Apple-picking season starts in January and runs for some
weeks, and the Pear-picking season starts in February (etc), then
calculation will reveal if one team of pickers can do both jobs or if
two teams will be needed. If a list of tasks is to be displayed/printed,
then it would be useful to list both, but in chronological order -
perhaps by start-date.
(this idea of possible application fails to illustrate a rationale for
some of the functionality listed, above, but you get the idea of how to
give us the idea...)

In a custom-class, an __eq__( self, other, ) may be defined to consider
any single or combination of attributes of the two classes. So,
roll-your-own may not be that difficult - although anything involving
time-calculations is wont to open a can-of-worms...

--
Regards,
=dn

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.

Cheers,
Cameron Simpson <cs@cskk.id.au>

Cameron Simpson <cs@cskk.id.au> writes:

> 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

--
This signature is currently under constuction.

On 3/29/2023 2:17 AM, Loris Bennett wrote:
>
> 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
>

Maybe there is - https://github.com/LinkCareServices/period

"Period is a basic time period checking library.

Period is based on period.py by William S. Annis. (available at
https://www.biostat.wisc.edu/~annis/creations/period.py.html) and ported
to python3 with a few improvements. Period.py was in part inspired by
perl's Time::Period module and the time class mechanism of Cfengine."

I have not worked with it, but it may be worth looking at. I found this
by going to PyPi.org and asking for "period".

On 29Mar2023 08:17, Loris Bennett <loris.bennett@fu-berlin.de> wrote:
>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.

Well, my attitude to time spans is to get the start and end (or start
and length, but I prefer the former) as UNIX timestamps and work from
that. I try to stay as far from datetimes as possible, because of their
foibles (particularly timezones, but really the whole calendar
decomposition etc) and use them only for presentation.

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

But it would be easy to give that class `__lt__` etc methods.

You're welcome to use it, or anything from the module (it's on PyPI).

Cheers,
Cameron Simpson <cs@cskk.id.au>