starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Support of correct timezone-based conditions in jsonata #3541

New issue

Open

opened 2026-02-28 03:33:00 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-28 03:33:00 -05:00

Owner

Originally created by @Adrian-Grimm on GitHub (Aug 14, 2024).

🏷️ Feature Request Type

Other

🔖 Feature description

Some JSON validations require a time based condition e.g. device states with time based states.
But in countries like Germany we have summer and winter time difference in offsets and the default $now() only supports a fixed timezone offset.

e.g.: $now('[H01]:[m01]', '+0200')

✔️ Solution

Integration of jsonata-moment for support of correct timely based conditions in summer and winter time with $moment()
https://github.com/elasticio/jsonata-moment

❓ Alternatives

No response

📝 Additional Context

https://github.com/jsonata-js/jsonata/issues/347

Originally created by @Adrian-Grimm on GitHub (Aug 14, 2024). ### 📑 I have found these related issues/pull requests - ### 🏷️ Feature Request Type Other ### 🔖 Feature description Some JSON validations require a time based condition e.g. device states with time based states. But in countries like Germany we have summer and winter time difference in offsets and the default `$now()` only supports a fixed timezone offset. e.g.: `$now('[H01]:[m01]', '+0200')` ### ✔️ Solution Integration of jsonata-moment for support of correct timely based conditions in summer and winter time with `$moment()` https://github.com/elasticio/jsonata-moment ### ❓ Alternatives _No response_ ### 📝 Additional Context https://github.com/jsonata-js/jsonata/issues/347

deekerman added the

feature-request

A:monitor

type:enhance-existing

labels

2026-02-28 03:33:00 -05:00

deekerman commented

2026-02-28 03:33:02 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 14, 2024):

I'd like to not add jet another datetime library.
I would prefer if jsonata would get the functionality to localize dates upstream instead.
=> Contributing a fix upstream is my preferred course of action

@CommanderStorm commented on GitHub (Aug 14, 2024): I'd like to not add jet another datetime library. I would prefer if jsonata would get the functionality to localize dates upstream instead. => Contributing a fix upstream is my preferred course of action

deekerman commented

2026-02-28 03:33:02 -05:00

Author

Owner

@Adrian-Grimm commented on GitHub (Aug 14, 2024):

@CommanderStorm The request is since 2019 open for such a feature - https://github.com/jsonata-js/jsonata/issues/347
quite unlikely to happn...

would you know a alternative aproach to solve this time based problem?

I could also think of making the monitors only time based "active"
A "cron" syntax style config option for execution could help and solve this also.
That could take care of local time of the environment TZ.

@Adrian-Grimm commented on GitHub (Aug 14, 2024): @CommanderStorm The request is since 2019 open for such a feature - https://github.com/jsonata-js/jsonata/issues/347 quite unlikely to happn... would you know a alternative aproach to solve this time based problem? I could also think of making the monitors only time based "active" A "cron" syntax style config option for execution could help and solve this also. That could take care of local time of the environment TZ.

deekerman commented

2026-02-28 03:33:03 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 14, 2024):

Yes, it has been a few years, but without anybody contributing a PR.
If someone contributes a PR upstream, I'd assume that they will review it.

As said:
I'd prefer if you'd contribute the functionality you need upstream.
we can add the plugin if upstream

rejects your PR or
comments that they'd like to keep it in a separate plugin

Monkeypatching functionality without a reason is not maintainable for us, sorry.

@CommanderStorm commented on GitHub (Aug 14, 2024): Yes, it has been a few years, but without anybody contributing a PR. If someone contributes a PR upstream, I'd assume that they will review it. As said: I'd prefer if you'd contribute the functionality you need upstream. we can add the plugin if upstream - rejects your PR or - comments that they'd like to keep it in a separate plugin Monkeypatching functionality without a reason is not maintainable for us, sorry.

deekerman commented

2026-02-28 03:33:03 -05:00

Author

Owner

@Adrian-Grimm commented on GitHub (Apr 19, 2025):

@CommanderStorm :
Fyi: Seems like a badly maintained project - I got no reply since August there:
https://github.com/jsonata-js/jsonata/issues/347#issuecomment-2293647619

@Adrian-Grimm commented on GitHub (Apr 19, 2025): @CommanderStorm : Fyi: Seems like a badly maintained project - I got no reply since August there: https://github.com/jsonata-js/jsonata/issues/347#issuecomment-2293647619

deekerman commented

2026-02-28 03:33:03 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Apr 19, 2025):

Consider opening up a PR instead. Commenting on an issue is something that requires a lot more effort to review, merge, ...

Also about the timing: once that notification gets clicked away as "I don't currently have the time" it does not reappear for maintainers. PRs are simpler to review.

@CommanderStorm commented on GitHub (Apr 19, 2025): Consider opening up a PR instead. Commenting on an issue is something that requires a lot more effort to review, merge, ... Also about the timing: once that notification gets clicked away as "I don't currently have the time" it does not reappear for maintainers. PRs are simpler to review.