Back in 2018 it “was considered” to add a function library for scripting, and input was requested for what functions would be useful to have: http://forum.mikrotik.com/t/built-in-function-library/117288/114
One of the first proposed category was manipulation of date/time values.
Unfortunately we never got that function library. If it had been implemented, the autodetection and handling of the new date format could just be added there, and all user scripts would automatically adapt to the new situation…
(or their programmer would be kicked for not using standard functions from the library)
Come on, it took me a moment to modify all my scripts on the forum and in production to be ready
for the 9 September for the long-term v7.23.5 where finally we can have the ISO time for Zero Trust on BFG (:P)… http://forum.mikrotik.com/t/routeros-v6-maintenance-mode/160861/1
I think the issue is not how much work it is for a capable programmer to modify the code, but more the vast number of copy/paste programmers that have tinkered a script that works and suddenly it breaks when upgrading. It may even take quite some time before that is noticed at all, e.g. when the script has some monitoring/alerting purpose.
In case some company has deployed hundreds of routers with some script, and did not think about an automated way for maintenance, it may be a big headache to fix.
But in general I agree that the number of scripts that parses a date field (rather than simply reading it and using it in some message) is probably quite small.
I have done some scripting but I never parsed the field, only copied it to a variable for later compare.
it’s also easy to update one or two devices, when you’ve got scripts baked into default setup scripts installed on thousands of devices spread all over the country, it’s a little more challenging to update. Thankfully this particular change does not affect any of our deployed scripts, only how we parse some data server side that gets retrieved from the API, so it’s an easy fix for us, but just because it’s an easy fix for us doesn’t mean MikroTik should get a free pass and break functionality for anyone who does have deployed scripts that might be affected by this. They absolutely should handle this change such that it does not become a new default setting when upgrading existing devices, and retain the old format as an option.
I hope the update process is not automatic (and neither is installing beta in production).
It is extremely easy, when you update the software, also update the scripts onboard of the machine…
And then, if years ago you had foreseen the self-updating of the onboard scripts… there’s nothing to worry about…
I want to emphasize that we welcome the new date format. HOWEVER, implementing it in a way that breaks compatibility, and in addition absolutely unnecessarily, is just plain stupidity.
And of course, you can “fix” the problem with various modifications, but the level of effort required varies depending on its occurrence. These type of changes is bound to have serious ramifications but the magnitude remains to be seen. People who don’t understand the implications of this issue shouldn’t comment on the matter IMO.
I have a similar problem. You load the returned date into a var then it appears I could only pick from position 0. After a bit of testing the pick function seems to have changed from the documentation. The syntax now appears to be :pick []. To get my scripts to work I have changed the values in the pick function.