[FEATURE] Support Relative Date-time Strings

[currantw]

Is your feature request related to a problem?

Support relative date-time strings similar to those supported in Splunk.

What solution would you like?

Implement support for relative date-time strings similar to those supported in Splunk, as described below. This should be integrated into the existing date-time implementation, such that date-time values that are declared using relative date-times can be compared and otherwise treated like any other date-time value.

Time Offset

The following time offset formats should be supported:

• [+|-]<time_integer><offset_time_unit>
• [+|-]<offset_time_unit>
• now

The following offset time unit keywords should be supported:

Description	Supported Keywords
seconds	s, sec, secs, second, seconds
minutes	m, min, mins, minute, minutes
hours	h, hr, hrs, hour, hours
days	d, day, days
weeks	w, week, weeks
month	mon, month, months
quarters	q, qtr, qtrs, quarter, quarters
year	y, yr, yrs, year, years

Snap-to Time Units

In addition to the supported time unit keywords listed above, the following keywords representing the days of the week should be supported for snap-to times:

Description	Supported Keywords
Sunday	w0, w7
Monday	w1
Tuesday	w2
Wednesday	w3
Thursday	w4
Friday	w5

Sunday should be considered to be to be the first day of the week, such that @w0, @w7, @w, and @week all correspond to the start of the previous Sunday. This is consistent with Splunk, but could be made configurable in the future if desired (i.e. so that Monday could be considered as the first day of the week).

Examples

Relative date-time	Description	Case
-60m	60 minutes ago	Offset without snap-to-time
-h	One hour ago	Offset without time integer
+2wk	Two weeks from now	Positive offset
-1h@h	1 hour ago, to the hour	Relative time with snap-to-time
@d	Beginning of the current day	Snap-to time without offset
-1d@w3	Last Wednesday	Weekday keyword
now	Current date-time	Current time keyword

The following functionality will not be supported (but could be supported in the future):

• Specifying offsets from the snap-to time (e.g. @d+12h).

What alternatives have you considered?

None. See #957.

Do you have any additional context?

See #957.

[currantw]

The following functionality will not be supported (but could be supported in the future):

• Specifying offsets from the snap-to time (e.g. @d+12h).

@YANG-DB Is this an acceptable limitation for the initial implementation? I think this covers the majority of use cases, and would allow us to get earliest/latest implemented a bit quicker. Once that's done, we can come back to add this functionality if it's needed.

[YANG-DB]

The following functionality will not be supported (but could be supported in the future):

• Specifying offsets from the snap-to time (e.g. @d+12h).

@YANG-DB Is this an acceptable limitation for the initial implementation? I think this covers the majority of use cases, and would allow us to get earliest/latest implemented a bit quicker. Once that's done, we can come back to add this functionality if it's needed.

Agree - thanks @currantw