PERSISTENT alarms can currently be configured with a grace period.
The grace period is specified as a number of seconds. This makes longer periods difficult to read and edit because the user must manually convert the desired duration into seconds.
For example, a two-hour grace period currently has to be written as:
7200
The intended duration is much clearer when written as:
2h
Proposed change
Replace the seconds-only format with a number followed by a time-unit suffix.
Supported suffixes:
Suffix
Unit
ms
millisecond
s
second
m
minute
h
hour
d
day
w
week
M
month
y
year
The suffixes are case-sensitive because:
m means minutes.
M means months.
Examples
500ms
30s
15m
2h
3d
1w
2M
1y
No combined durations
Only one numeric value and one unit shall be supported.
The following are intentionally not supported:
1w3d
2h30m
1y6M
Instead, the duration should be expressed using a single unit, for example:
10d
Validation
The configuration parser should reject values that:
Do not contain a supported suffix.
Contain more than one duration component.
Contain an unknown suffix.
Contain a negative duration.
Contain trailing or otherwise unrecognised characters.
Examples of invalid values:
7200
1w3d
2hours
-5m
5x
The resulting error should identify the invalid grace-period value and list the supported suffixes.
Month and year semantics
Because months and years do not have a constant duration, the implementation should define them as fixed durations:
1M = 30 days
1y = 365 days
Acceptance criteria
PERSISTENT alarms can use values such as 500ms, 30s, 15m, 2h, 3d, 1w, 2M and 1y.
The configured value is converted into the duration used internally by the alarm.
Unit suffixes are case-sensitive.
Only one duration component is accepted.
Plain numbers without a suffix are rejected.
Invalid values produce a clear configuration error.
Benefits
Grace periods become much easier to read.
Longer durations can be changed without using a calculator.
Configuration mistakes become less likely.
The configuration remains compact and easy to understand.
## Background
`PERSISTENT` alarms can currently be configured with a grace period.
The grace period is specified as a number of seconds. This makes longer periods difficult to read and edit because the user must manually convert the desired duration into seconds.
For example, a two-hour grace period currently has to be written as:
```text
7200
```
The intended duration is much clearer when written as:
```text
2h
```
## Proposed change
Replace the seconds-only format with a number followed by a time-unit suffix.
Supported suffixes:
| Suffix | Unit |
|--------|------|
| `ms` | millisecond |
| `s` | second |
| `m` | minute |
| `h` | hour |
| `d` | day |
| `w` | week |
| `M` | month |
| `y` | year |
The suffixes are case-sensitive because:
- `m` means minutes.
- `M` means months.
## Examples
```text
500ms
30s
15m
2h
3d
1w
2M
1y
```
## No combined durations
Only one numeric value and one unit shall be supported.
The following are intentionally **not** supported:
```text
1w3d
2h30m
1y6M
```
Instead, the duration should be expressed using a single unit, for example:
```text
10d
```
## Validation
The configuration parser should reject values that:
- Do not contain a supported suffix.
- Contain more than one duration component.
- Contain an unknown suffix.
- Contain a negative duration.
- Contain trailing or otherwise unrecognised characters.
Examples of invalid values:
```text
7200
1w3d
2hours
-5m
5x
```
The resulting error should identify the invalid grace-period value and list the supported suffixes.
## Month and year semantics
Because months and years do not have a constant duration, the implementation should define them as fixed durations:
- `1M = 30 days`
- `1y = 365 days`
## Acceptance criteria
- `PERSISTENT` alarms can use values such as `500ms`, `30s`, `15m`, `2h`, `3d`, `1w`, `2M` and `1y`.
- The configured value is converted into the duration used internally by the alarm.
- Unit suffixes are case-sensitive.
- Only one duration component is accepted.
- Plain numbers without a suffix are rejected.
- Invalid values produce a clear configuration error.
## Benefits
- Grace periods become much easier to read.
- Longer durations can be changed without using a calculator.
- Configuration mistakes become less likely.
- The configuration remains compact and easy to understand.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Background
PERSISTENTalarms can currently be configured with a grace period.The grace period is specified as a number of seconds. This makes longer periods difficult to read and edit because the user must manually convert the desired duration into seconds.
For example, a two-hour grace period currently has to be written as:
The intended duration is much clearer when written as:
Proposed change
Replace the seconds-only format with a number followed by a time-unit suffix.
Supported suffixes:
mssmhdwMyThe suffixes are case-sensitive because:
mmeans minutes.Mmeans months.Examples
No combined durations
Only one numeric value and one unit shall be supported.
The following are intentionally not supported:
Instead, the duration should be expressed using a single unit, for example:
Validation
The configuration parser should reject values that:
Examples of invalid values:
The resulting error should identify the invalid grace-period value and list the supported suffixes.
Month and year semantics
Because months and years do not have a constant duration, the implementation should define them as fixed durations:
1M = 30 days1y = 365 daysAcceptance criteria
PERSISTENTalarms can use values such as500ms,30s,15m,2h,3d,1w,2Mand1y.Benefits