Re: Pre-Pre-PEP: The datetime.timedeltacal class
On Sat, Apr 16, 2022, at 13:35, Peter J. Holzer wrote: > When adding a timedeltacal object to a datetime, the fields are added > from most to least significant: First a new date is computed by > advancing the number of months specified [TODO: Research how other > systems handle overflow (e.g. 2022-01-31 + 1 month: 2022-02-31 doesn't > exist)], then advance the number of days. Finally add the number of > seconds and microseconds, taking into accout daylight savings time > switches if the datetime is time zone aware. > > Subtracting a timedeltacal object from a datetime is the same, just in > the opposite direction. > > Note that t + d - d is in general not equal to t. I'm not sure there's a guarantee that t + n day + m second may not be equal to t + m second + n day, either. This is possibly also something that we can look at what existing implementations do, though I'm concerned that the choice of "fold" rather than "isdst" may come back to bite us here [C actually uses a three-state isdst input for mktime which performs these operations] Also, what about hours? "12 calendar hours" may be 13 or 11 hours depending on if a DST transition is included in the given time. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
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. A timedelta of one day is 86400 seconds.
The thing you *think* timedelta does [making a day act as 23 or 25 hours across
daylight saving boundaries etc], that you *don't* want it to do, is something
it *does not actually do*. I don't know how this can be made more clear to you.
timedelta is what you need. if you think it's not, it's because you're using
datetime incorrectly.
The real problem is that naive datetime objects [without using either a fixed
timezone offset like the built-in utc, or a library like pytz] are not fit for
any purpose.
If you use pytz correctly [which is unfortunately awkward due to leaky
abstractions and mismatches between the datetime model works and how most
people expect datetimes with timezones to work], you will indeed get 24 hours
from timedelta(days=1)
>>> et = pytz.timezone('America/New_York')
>>> 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't even have a way to represent "1 day" [or 1
month, 1 year] as a context-dependent-length interval (the thing you think
timedelta does), at least not within the standard library and the datetime
model.
> 11-22::44:55
>
> (These are the lengths of time a job has run on an HPC system - leap
> seconds and time zones are of no relevance).
>
> It is obviously fairly easy to rustle up something to do this, but I am
> surprised that this is not baked into Python (such a class also seems to
> be missing from R). I would have thought that periods crop up all over
> the place and therefore formatting as strings and parsing of string
> would be supported natively by most modern languages. Apparently not.
>
> Cheers,
>
> Loris
>
> --
> This signature is currently under construction.
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
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 >> by a day. > > Leap century is skip unless it’s a leap quadra century. Indeed, which is why "leap=not year & 3" works for years in range(1901, 2100). Which I have found useful before when programming in an assembly language that has no division operation ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
> 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 it’s a leap quadra century. Barry -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
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 Supplement to the Astronomical Almanac (table 15.3) defines the /day/ as 24hrs->1440mins->86400secs BUT defines the Julian /year/ as 365.25 days. So, a /day/ is a solar day, as distinct from a sidereal day. What's the difference? Well, a "sidereal day" is how long it takes for the Earth to rotate on its axis, but as it's also orbiting the Sun in the same direction, midday won't happen until a little later, hence "solar day". [snip] -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
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.3)
defines the /day/ as 24hrs->1440mins->86400secs BUT defines the
Julian
/year/ as 365.25 days.
It goes on to also give (for my copy -- length of year at 1990):
Tropical (equinox to equinox) 365.2421897 days *
Sidereal (fixed star to fixed star) 365.25636 days
Anomalistic (perihelion to perihelion) 365.25964 days
Eclipse (moon's node to moon's node)346.26005
Gaussian (Kepler's law /a/=1) 365.25690
Julian 365.25
Length of the month (I interpret this as lunar month):
Synodic (new moon to new moon) 29.53059 days
Tropical (as with year) 27.32158
Sidereal (as with year) 27.32166
Anomalistic (perigee to perigee)27.55455
Draconic (node to node) 27.21222
* 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.
Of course, this book also has a footnote giving the speed of light as
1.80261750E12 Furlongs/Fortnight
However, as soon you incorporate units that are not SI seconds you have
to differentiate between pure duration (based on SI seconds) and civil time
(which may jump when leap seconds are added/subtracted, time zones are
crossed, or daylight savings time goes into [or out of] effect).
For the most part, Python's datetime module seems to account for civil
time concepts, not monotonic durations.
The Ada standard separates "duration" (as a measure of elapsed time, in
fixed point seconds) from "time" (a private type in Ada.Calendar -- which
does NOT define hours/minutes... It has Year 1901..2399, Month 1..12, Day
1..31, Day_duration 0.0..86400.0). There are functions to create a Time
from components, split a Time into components, compare two times, add a
Duration to a Time, subtract a Duration from a Time, and subtract a Time
from a Time (getting a Duration). Oh, and a function to get Time from
system clock. Per the standard, the Time Zone used is implementation
defined (so one needs to read the implementation manual to find out what a
Time really notates). Of note:
"""
26.a/1
To be honest: {8652/0106} {AI95-00160-01} By "proper date" above we mean
that the given year has a month with the given day. For example, February
29th is a proper date only for a leap year. We do not mean to include the
Seconds in this notion; in particular, we do not mean to require
implementations to check for the “missing hour” that occurs when Daylight
Savings Time starts in the spring.
"""
"""
43
type Duration is delta implementation-defined range
implementation-defined;
"""
GNAT provides an extension package GNAT.Calendar that adds
hour/minute/day-of-week and some other utilities... BUT
"""
procedure Split_At_Locale
(Date : Ada.Calendar.Time;
Year : out Ada.Calendar.Year_Number;
Month : out Ada.Calendar.Month_Number;
Day: out Ada.Calendar.Day_Number;
Hour : out Hour_Number;
Minute : out Minute_Number;
Second : out Second_Number;
Sub_Second : out Second_Duration);
-- Split a standard Ada.Calendar.Time value in date data (Year, Month,
Day)
-- and Time data (Hour, Minute, Second, Sub_Second). This version of
Split
-- utilizes the time zone and DST bias of the locale (equivalent to
Clock).
-- Due to this simplified behavior, the implementation does not require
-- expensive system calls on targets such as Windows.
-- WARNING: Split_At_Locale is no longer aware of historic events and
may
-- produce inaccurate results over DST changes which occurred in the
past.
"""
--
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
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 run on an HPC system - leap > seconds and time zones are of no relevance). Thing is, there's a huge difference between: 1) "Eleven days, twenty-two hours, forty-four minutes, and fifty-five seconds" 2) "The period between 2nd May 2009 at 6AM and 5th June 2010 at 9AM" 3) "The period between 20th Feb 2016 at 10PM in New York and 30th Mar 2016 at 1AM in New York" 3b) "The period between 23rd Jan 1918 and 15th Feb 1918 in Moscow" The first one is an abstract distance of time, and could be considered broadly equivalent to the difference between two TIA timestamps or two Unix times. Or UTC, as long as you don't care about inaccuracy around leap seconds. The second is a specific time period without a time zone. If assumed to be UTC, or on an abstract calendar, it can be converted to and from the first form, but if it's assumed to be local time, then it's underspecified. It's affected by leap years, so you have to specify the full date. The third, and possibly fourth, are affected by civil time. (3b is also potentially affected by a calendar switch; for people in Russia at the time, the 23rd of January was a Julian date and the 15th of February was a Gregorian date, so they were closer together than on either calendar consistently. But I'd be fine with ignoring that, and requiring the use of the Gregorian (or ISO, which is derived from it) calendar.) Civil time is modified by regular adjustments (mostly DST), official changes to time zone (eg the introduction or abolition of DST, or choosing to align one's timezone with a neighbour), adoption of standard time (often adjusting by a few minutes and/or seconds to align with an hour boundary), etc, etc, etc. The only way to handle civil time is (a) with full timestamps including the year, and (b) with a complete timezone database listing all conversions. At this point, the time period no longer has any abstract meaning, and its sole meaning is "the time between these instants"; as such, it's probably best calculated by converting the timestamps to UTC, converting to Unix time, and taking the difference in seconds. With the first option, there's no real meaning to it until you figure out what you can actually *do* with that time period. I believe ISO 8601 timestamps are about the most general you'll ever need, with the possible exception of "9pm to 10pm second Saturday of every month, if His Sufficiency feels like meeting with you, otherwise never". (Though, to be fair, you could probably represent that with a simple "Never" and it'd be just as correct.) It's worth noting that pure seconds can easily be used as timedeltas. If you want your form to be convertible back and forth with a number of seconds, it's easy enough to subtract two datetimes by their Unix times. But before defining the class, it's essential to define what you want to do with it. Not all operations are equally meaningful. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
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 of years which start on a given date to all end on the >> same date. >> >> In my little niche, I just need a very simple period and am anyway not >> bothered about years, since in my case the number of days is usually >> capped at 14 and only in extremely exceptional circumstances could it >> get up to anywhere near 100. >> >> However, surely there are plenty of people measuring durations of a few >> hours or less who don't want to have to deal with seconds all the time >> (I am in fact also in this other group when I record my working hours). > > Well, that's my point. Everyone's all in their own slightly-different > little niches. There isn't one straightforward standard that makes all > or even most of them happy. I'm sure you're right. I just strikes me as a little odd that so much effort has gone into datetime to make things work (almost) properly for (almost) everyone, whereas timedelta has remained rather rudimentary, at least in terms of formatting. It seems to me that periods on the order of hours would have quite generic applications, but maybe that's just the view from my niche. Cheers, Loris -- This signature is currently under construction. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
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 given date to all end on the > same date. > > In my little niche, I just need a very simple period and am anyway not > bothered about years, since in my case the number of days is usually > capped at 14 and only in extremely exceptional circumstances could it > get up to anywhere near 100. > > However, surely there are plenty of people measuring durations of a few > hours or less who don't want to have to deal with seconds all the time > (I am in fact also in this other group when I record my working hours). Well, that's my point. Everyone's all in their own slightly-different little niches. There isn't one straightforward standard that makes all or even most of them happy. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
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 back and forth from a format such as >>> >>> 11-22::44:55 >> >> I don't recognise that format and can't work out what it means. >> It should be trivial to write functions to parse whatever format >> you wanted and convert between it and timedelta objects though. > > days-hours:minutes:seconds If by 'days' it means '86,400 seconds' then that's very easily convertible to and from timedelta. >> I would be very surprised if any language supported the arbitrary format >> above you happen to be interested in! > > But most languages support fairly arbitrary formatting of timedate-style > objects. It doesn't seem unreasonable to me that such formatting might > be available for simple periods. > >>> I would have thought that periods crop up all over >>> the place and therefore formatting as strings and parsing of string >>> would be supported natively by most modern languages. Apparently not. >> >> I think most languages think that a simple number suffices to represent >> a fixed time period (commonly seconds or milliseconds). And if you want >> more dynamic intervals (e.g. x months y days) then there is insufficient >> consensus as to what that actually means. > > Maybe. It just seems to me that once you get up to more than a few > hundred seconds, the ability to convert and from a more readable format > becomes very useful. The length of a month may be unclear, but the > definitions for year, week, day, hours, and minute are all trivial. Eh? The definitions for "year, week, day" are not in the slightest bit trivial (unless you define 'day' as '86,400 seconds', in which case 'year' is still not remotely trivial). I think the issue is simply lack of consensus. Even though ISO 8601, which is extremely common (possibly even ubiquitous, for anything modern) for the format of date/times, also defines a format for durations (e.g. 'P4Y3M' for '4 years 3 months'), I don't think I have ever seen it used in practice - not least because apparently it doesn't define what it actually means. So there isn't one simple standard agreed by everyone that is an obvious candidate for inclusion in language standard libraries. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
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-22::44:55 > > I don't recognise that format and can't work out what it means. > It should be trivial to write functions to parse whatever format > you wanted and convert between it and timedelta objects though. days-hours:minutes:seconds >> It is obviously fairly easy to rustle up something to do this, but I am >> surprised that this is not baked into Python (such a class also seems to >> be missing from R). > > I would be very surprised if any language supported the arbitrary format > above you happen to be interested in! But most languages support fairly arbitrary formatting of timedate-style objects. It doesn't seem unreasonable to me that such formatting might be available for simple periods. >> I would have thought that periods crop up all over >> the place and therefore formatting as strings and parsing of string >> would be supported natively by most modern languages. Apparently not. > > I think most languages think that a simple number suffices to represent > a fixed time period (commonly seconds or milliseconds). And if you want > more dynamic intervals (e.g. x months y days) then there is insufficient > consensus as to what that actually means. Maybe. It just seems to me that once you get up to more than a few hundred seconds, the ability to convert and from a more readable format becomes very useful. The length of a month may be unclear, but the definitions for year, week, day, hours, and minute are all trivial. Cheers, Loris -- This signature is currently under construction. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
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 format and can't work out what it means. It should be trivial to write functions to parse whatever format you wanted and convert between it and timedelta objects though. > It is obviously fairly easy to rustle up something to do this, but I am > surprised that this is not baked into Python (such a class also seems to > be missing from R). I would be very surprised if any language supported the arbitrary format above you happen to be interested in! > I would have thought that periods crop up all over > the place and therefore formatting as strings and parsing of string > would be supported natively by most modern languages. Apparently not. I think most languages think that a simple number suffices to represent a fixed time period (commonly seconds or milliseconds). And if you want more dynamic intervals (e.g. x months y days) then there is insufficient consensus as to what that actually means. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
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. >>> that I can convert back and forth from a format such as 11-22::44:55 >>> >>> I don't recognise that format and can't work out what it means. >>> It should be trivial to write functions to parse whatever format >>> you wanted and convert between it and timedelta objects though. >> >> days-hours:minutes:seconds > > If by 'days' it means '86,400 seconds' then that's very easily > convertible to and from timedelta. > >>> I would be very surprised if any language supported the arbitrary format >>> above you happen to be interested in! >> >> But most languages support fairly arbitrary formatting of timedate-style >> objects. It doesn't seem unreasonable to me that such formatting might >> be available for simple periods. >> I would have thought that periods crop up all over the place and therefore formatting as strings and parsing of string would be supported natively by most modern languages. Apparently not. >>> >>> I think most languages think that a simple number suffices to represent >>> a fixed time period (commonly seconds or milliseconds). And if you want >>> more dynamic intervals (e.g. x months y days) then there is insufficient >>> consensus as to what that actually means. >> >> Maybe. It just seems to me that once you get up to more than a few >> hundred seconds, the ability to convert and from a more readable format >> becomes very useful. The length of a month may be unclear, but the >> definitions for year, week, day, hours, and minute are all trivial. > > Eh? The definitions for "year, week, day" are not in the slightest bit > trivial (unless you define 'day' as '86,400 seconds', in which case > 'year' is still not remotely trivial). Yes, I do mean just the trivial definitions from https://docs.python.org/3/library/datetime.html i.e. A millisecond is converted to 1000 microseconds. A minute is converted to 60 seconds. An hour is converted to 3600 seconds. A week is converted to 7 days. plus a 24-hour day and a 365-day year. > I think the issue is simply lack of consensus. Even though ISO 8601, > which is extremely common (possibly even ubiquitous, for anything > modern) for the format of date/times, also defines a format for > durations (e.g. 'P4Y3M' for '4 years 3 months'), I don't think > I have ever seen it used in practice - not least because apparently > it doesn't define what it actually means. So there isn't one simple > standard agreed by everyone that is an obvious candidate for inclusion > in language standard libraries. 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 given date to all end on the same date. In my little niche, I just need a very simple period and am anyway not bothered about years, since in my case the number of days is usually capped at 14 and only in extremely exceptional circumstances could it get up to anywhere near 100. However, surely there are plenty of people measuring durations of a few hours or less who don't want to have to deal with seconds all the time (I am in fact also in this other group when I record my working hours). Cheers, Loris -- This signature is currently under construction. -- https://mail.python.org/mailman/listinfo/python-list
Re: Why does datetime.timedelta only have the attributes 'days' and 'seconds'?
"Peter J. Holzer" writes:
> On 2022-04-16 20:35:22 -, Jon Ribbens via Python-list wrote:
>> On 2022-04-16, Peter J. Holzer wrote:
>> > On 2022-04-16 14:22:04 -, Jon Ribbens via Python-list wrote:
>> >> ... although now having looked into the new 'zoneinfo' module slightly,
>> >> it really should have a giant red flashing notice at the top of it
>> >> saying "BEWARE, TIMEZONES IN PYTHON ARE UTTERLY BROKEN, NEVER USE THEM".
>> >>
>> >> 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)
>> >> >>> print(d)
>> >> 2020-10-31 12:00:00-07:00
>> >> >>> d1 = d + datetime.timedelta(days=1)
>> >> >>> print(d1)
>> >> 2020-11-01 12:00:00-08:00
>> >>
>> >> d1 is *wrong*.
>> >
>> > No, this is correct. That's the result you want.
>>
>> 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 Python, how do I do it?
>
> What you *should* be able to do is use datetime.timedelta(hours=24).
>
> Unfortunately, you can't, because somebody decided to add a
> normalization rule to timedelta which turns this into timedelta(days=1,
> hours=0).
>
>> It would appear that, without converting to UTC before doing the
>> calculation, you can't.
>
> When doing calculations of this kind I frankly prefer converting to
> "seconds since the epoch" and doing simple arithmetic. (Yes, leap
> seconds, I know .. I just ignore those)
>
>
>> > So why didn't this work for me (I also used Python 3.9)? My guess is
>> > that astimezone() doesn't pick the correct time zone.
>>
>> astimezone() doesn't pick a time zone at all. It works out the current
>> local offset from UTC.
>
> The timezone object it returns also includes a timezone string ("CET" in
> my example). So it's not *just* the offset. The result is misleading,
> though. You get something which looks like it's a timezone object for
> Central European Time, but isn't.
>
>> It doesn't know anything about when or if that
>> offset ever changes.
>
> astimezone() doesn't have to. It just has to pick the correct timezone
> object. That object then knows about offset changes.
>
>
>> >> timedelta(days=1) is 24 hours (as you can check by
>> >> calling timedelta(days=1).total_seconds() ),
>> >
>> > It shouldn't be. 1 Day is not 24 hours in the real world.
>>
>> Nevertheless, timedelta is a fixed time period so that is the only
>> definition possible.
>
> Yeah, you keep repeating that. I think we are talking at cross-purposes
> here. You are talking about how timedelta is implemented while I'm
> talking what semantics it *should* have.
>
>
>> >> It appears that with Python it's not so much a guideline as an
>> >> absolute concrete rule, and not because programmers will introduce
>> >> bugs, but because you need to avoid bugs in the standard library!
>> >
>> > As a programmer you must always adapt to the problem. Saying "I must do
>> > it the wrong way because my library is buggy" is just lazy.
>>
>> I didn't say any of that. I said you must do it the conservative way,
>> and it's not "my library" that's buggy, it's the language's built-in
>> *standard library* that's buggy.
>
> With "your library" I meant "the library you have" not "the library you
> wrote". And while having a buggy (or just badly designed) standard
> library is especially annoying, you still aren't forced to use it if if
> doesn't fit your needs.
>
> hp
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 run on an HPC system - leap
seconds and time zones are of no relevance).
It is obviously fairly easy to rustle up something to do this, but I am
surprised that this is not baked into Python (such a class also seems to
be missing from R). I would have thought that periods crop up all over
the place and therefore formatting as strings and parsing of string
would be supported natively by most modern languages. Apparently not.
Cheers,
Loris
--
This signature is currently under construction.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Tuple unpacking inside lambda expressions
Op 16/04/2022 om 23:36 schreef Sam Ezeh: Two questions here. Firstly, does anybody know of existing discussions (e.g. on here or on python-ideas) relating to unpacking inside lambda expressions? I found myself wanting to write the following. ``` map( lambda (module, data): result.process(module, data), jobs ) ``` However, it's of course not legal Python syntax. Why not write: itertools.starmap(result.process, jobs) -- https://mail.python.org/mailman/listinfo/python-list
