Add Support for days configuration

[imne]

Describe the feature request

please add the ability to be able to configure the condition via days instead of only hours

because the problem is the alerts look like this, and it's not very user friendly and you now need to convert the hours to days in order to see how long the duration is

Why do you personally want this feature to be implemented?

improve the user experience

How long have you been using this project?

No response

Additional information

No response

[mehdibo]

Is this something to implement? if so I'd be happy to take a look at it

[TwiN]

I know this is going to rub some people the wrong way, but while I understand your stance, I would rather not move away from Go's time package, and I think the real issue here is that Go's maintainers refuse to add day as a duration unit because a day isn't theoretically always 24h.

golang/go#11473

[mehdibo]

@TwiN I don't think it makes sense to limit the features with the underlying language's limitation. The discussion there is one of precision.
In Gatus's context, if I use the day unit a small (even big) difference is tolerable, it is just an improvement to the UX.
If I want to make sure the certificate is not due until at least 30days, it doesn't matter if Gatus will notify me in 29 or 31 days, imho you need to re-consider the issue with implementing the day unit in the project's scope and not the technology's.

Edit:
Worst case we can convert the value 7d to 24h * 7 behind the scenes, and improve the display to use the biggest unit possible

[imne]

@TwiN I don't think it makes sense to limit the features with the underlying language's limitation. The discussion there is one of precision. In Gatus's context, if I use the day unit a small (even big) difference is tolerable, it is just an improvement to the UX. If I want to make sure the certificate is not due until at least 30days, it doesn't matter if Gatus will notify me in 29 or 31 days, imho you need to re-consider the issue with implementing the day unit in the project's scope and not the technology's.

Edit: Worst case we can convert the value 7d to 24h * 7 behind the scenes, and improve the display to use the biggest unit possible

100% agree, doesn't make sense not implementing an enhancement because the base language didn't implement it, also it would be more user friendly to have the alert that goes out to actually show the metric you decided to use instead of the millisecond difference, i.e
if a setup an alert to notify me 5 hours before a cert expiring the should maybe say 4h > 5h for example or if the alert is in days then something like 1d > 2d

instead of you needing to calculate the times

[TwiN]

I understand what you're both saying, but again, I would rather not stray away from the time package.

If there's a way to implement it without using a custom type, I'm open to it.

If I remember correctly, there's a package called str2duration, that may be a good starting point