WARNING: RouterOS v7.10+ will break all scripts based on [/system clock get date] or other date(s)
The new RouterOS v7.10+ changes the date reported by [/system clock get date] from may/10/2023 to the correct ISO 2023-05-10 format.
(and probably all other points where can be retrieved one date, like on /log, /certificate, /system scheduler, address-list entry creation-time, etc.)
THIS IS NECESSARY AND HAD TO BE DONE BEFORE,
hopefully it’s a right step in the direction of standardizing all dates in ISO format even within LOG and other places where the date is misspelled.
BUT… this means that: All old scripts containing [/system clock get date] will stop working properly from v7.10+
Not only on [/system clock get date], but on every other places where date is used:warning:
Nice that the date format issue is finally being addressed even if the initial implementation creates compatibility issues completely unnecessarily IMO. Seriously Mikrotik, please consider a different implementation.
IMO, a much better and general solution would be to let the “date” function work as before but expanded it with arguments using Linux date-format strings something like
[/system clock get date "%h %m %s"]
The other suggestions like “isodate” would also work but I like my solution better (obviously) because of its additional benefits. Ammo’s “:timestamp” is also great and “:todate” could also be extended to take date format arguments.
In addition, it is my strong belief that “/system clock set format=” should be implemented regardless and should affect the entire system such as the log, console, etc.
absolutely fully and wholeheartedly agree 100% with this idea. this is the only way it should be done, and then ALL date/time fields in ROS, terminal winbox and webfig, should be displayed using this format. Once this is implemented and rolled out & tested, then you can change the default date/time format in a future ROS release to be the ISO standard without breaking much of anything for anyone.
What I don’t understand is why the new date format is implemented only for console, and only in very limited cases.
The first log message I see already breaks the new system: 14:27:56 system,info ntp change time May/10/2023 14:27:56 => May/10/2023 14:27:56
I mean, was it really that difficult to make the change EVERYWHERE at the same time? I presume RouterOS uses functions for things like this…
And indeed: the “shortened” version of date/time should go. A log message should not have only a timestamp, as above, but always a full date/time.
IMO, it should never ever be mandatory to make a system-wide change just because someone want decent and flexible date values for scripting.
You might have missed it, but as I’ve already mentioned in my previously post: the best solution would be a combination where you can both use a flexible date management for scripting as well as a system-wide setting. Note, both optional and not one or the other!
For scripting (or whatever similar command using linux date format):
[/system clock get date format="%h %m %s"]
AND/OR:
set a system-wide format like your suggestion:
/system clock set format="%YYYY-%MM-%DD-%hh:%mm:%ss"
@Larsa,
you don’t understand the meaning:
It takes MikroTik programmers decades to do something,
so currently they have two methods, the new one, and the old one.
Do you think they start making one that includes “%x” variables? (I made one like that, if you need…)
The best thing you can do, to make him want to do it, is a very trivial parameter that decides which format to use,
so you are perfectly in control of how date is handled in that RouterBOARD globally.
Do you understand now, or will you ignore it???
For me the only valid format should be Unix Epoc everywhere, and if you want to read the date in plain text, convert it.
WARNING: RouterOS v7.10+ will break all scripts based on [/system clock get date] or other date(s)
