Actions
Bug #1229
openflt.utils.trimmer: with no date, beginning time cannot be greater than end time
Start date:
02/17/2020
Due date:
% Done:
0%
Estimated time:
Description
If you specify
begin="22:34", end="02:17"
to flt.utils.trimmer, it fails to initialize and logs that the the beginning time is greater than the end time.
However, it is implicit that, without dates specified, any combination of beginning and end times is correct, and we assume a maximum delta of 23h59:59.999999999. In other words, in the example above, we want to trim from 22:34 to 2:17 the following day.
Would this be accepted:
begin="2019-04-11 22:34", end="02:17"
Or this:
begin="22:34", end="2019-04-12 02:17"
If so, we don't need any message to deduce the end time's date. But this is not currently supported.
Updated by Jonathan Rajotte Julien almost 5 years ago
Follow-up:
From Simon Marchi:
If we follow these rules, I think it should be easy to implement and natural to use: For begin: - if a date is specified, use that - if no date is specified, use the date of the first event For end: - if a date is specified, use that - if no date is specified, use the first instance of that time that follows begin (which is another way of saying "we assume a maximum delta of 23h59:59.999999999") After doing this, we can check if end < begin, which should only be possible if the user has provided an end date.
From Jonathan Rajotte:
This is usability related. Moving to 2.1. Current user can specify the date directly.
Updated by Jonathan Rajotte Julien almost 5 years ago
- Related to Bug #1230: flt.utils.trimmer: local time can be nonexistent or ambiguous with DST added
Updated by Jonathan Rajotte Julien almost 5 years ago
- Author changed from 215 to 22
Updated by Jonathan Rajotte Julien almost 5 years ago
Migrated from internal bug tracker.
Actions