[time] isBefore/isAfter missing

[maniac103]

The time library provides a very nice ZonedDateTime.isBetweenTimes method. If I don't need a 'between' check, but only an after/before check, I need to fall back to LocalTime, creating inconsistent code:

var time1 = time.toZDT();
var time2 = time.toZDT();
var check1 = time.toZDT().isBetweenTimes(time1, time2); // nice
var check2 = time.toZDT().toLocalDateTime().isAfter(time1.toLocalDateTime()); // not nice

It would be great if the library could provide additions for isBefore/isAfter for ZonedDateTime.

[florian-h05]

Do you think you can contribute this yourself?

As an example, you can find the code for isBetweenTimes here: https://github.com/openhab/openhab-js/blob/dc14c50fccd005d29025651c82b3fee6348b10d5/time.js#L312

[maniac103]

I think so, yes. I'll give it a shot; just wanted to check your opinion first.

[florian-h05]

👍

I would add the following:

• isAfterTime/isBeforeTime (only compares the time part, accounts midnight)
• isAfterDate/isBeforeDate (only compares the date part)
• isAfterDateTime/isBeforeDateTime (compares both time and date)

Also have a look at the CONTRIBUTING.md for code style and type defs.

[maniac103]

Why not stay with isBefore and isAfter? That way

• the API is consistent (there's no isBetweenDates, and isBetweenTimes would do a different thing than e.g. isBeforeTime)
• there's no potential time zone confusion ( e.g. would "2023-05-01 00:00 -05:00".isBeforeDate("2023-05-01 00:00 +01:00") return true or false?)

[florian-h05]

We already have these:

• isBetweenTimes: compares time portions and accounts midnight
• isBetweenDates: compares date portions
• isBetweenDateTimes: compares both the time & date

See https://github.com/openhab/openhab-js#isbetweentimesstart-end.

Therefore I‘d like to have the before and after checks to have these three different „modes“ as well to have a consistent API.

there's no potential time zone confusion ( e.g. would "2023-05-01 00:00 -05:00".isBeforeDate("2023-05-01 00:00 +01:00") return true or false?)

I guess .toLocalDate returns a LocalDate that takes the zone into account. Depending on your location this will either be true or false. The time zone confusion is no argument against providing these three methods.

[maniac103]

Okay, fair enough. I'll implement that.