Yes my friend, I actually do understand. As for the Linux date format, it’s really nothing new and has been used for decades in the Linux/RoS standard libraries. And the same goes for linux timestamp that probably would be quite easy to implenent as a global var or function call.
However to be honest, a system wide date format is probably a much bigger change than just adding a flexible date format for scipting. But I still hope they will implement it some day.
I don’t think anyone disagrees with:
But quibbling about %'s vs DD seems a bit premature.
At this point, we’re taking about the output of “clock get” to avoid the need to parse English month names… Nothing more is included AFAIK (yet?). While tend to agree with @rextended YYYYMMDD style seems more intuitive/modern – but be long wait for either %D or DD formatters I’m sure 
The ISO fix for /system clock is for sure a step in right direction…but doesn’t really solve the TWO use cases:
And for sure they should same formatters, but I’m really not whether the % is the most important part here…
Larsa you have the greatest potential to sway MT folks to do the right thing.
Threaten them that Santa will not send any toys to their children if they do not fix right away.
The change notes said:
*) console - changed time format according to ISO standard;
So I expected any date/time output visible on the console to have changed to ISO standard. Not limited (or maybe not even including) “clock get”.
And indeed, when I print /ip/firewall/address-list I do get the new format. But not in the message logged by NTP.
From first post, I update it over time:
Regardless of which solution one might prefer, I’m pretty sure most people agree that the current solution in v7.10b should be redone to restore script compatibility.
NO, it’s better to “fix” the scripts (very easy) than revert to the previous shitty format
You’re not alone on this planet 
Reverting to old format and provide parallel new format is easier for everyone.
Anyone wanting to use the new format, has to do something anyhow.
Who wants to keep using the old format … not so much.
In your suggestion, EVERYONE needs to do something.
And these “Everyone” should still install 7.10(beta 5), so something they should do anyway… 
The same is also true in reverse: not everyone installs custom scripts, and of those who install custom scripts, only a small part involves dates…
Professional users (unless forced due to lack of downgrade) continue to use v6 as much as possible.
Updating a script takes a moment, and until you install v7.10+ you’re not stuck.
Very easy to make a self-adapting script…
Non-professional users rarely have scripts installed separately.
How many do you want there to be?
And of these scripts, apart from @ElDoncito, very few are about dates…
Just updated some scripts with the autodetect:
http://forum.mikrotik.com/t/changing-the-mmm-dd-yyyy-date-format/5183/10
http://forum.mikrotik.com/t/sorted-array-of-files/151870/2
http://forum.mikrotik.com/t/convert-uptime-to-date-and-time/157724/5
http://forum.mikrotik.com/t/i-did-it-script-to-compute-unix-time/68576/24
Breaking script compatibility in the middle of a major revision is not a trivial task and should be taken very seriously.
It may not be a significant concern for a garage-based company full of hacker heros, but for a serious corporation with a large installation base, it might have a profound impact. IMO, the current implementation is ill-conceived, particularly considering that there are much smoother ways to resolve it while still preserving strict compatibility.
Bottom line; Mikrotik must really make every effort to prevent compatibility issues in future releases. Otherwise, Mikrotik runs the risk of introducing yet another showstopper that makes it even harder upgrading to v7.
Mikrotik, this is a matter of utmost importance!
Agreed, breaking functionality is a huge no-no. It is always acceptable to add something new, but changing existing functionality that can break established processes is a horrible idea. I fully support standardizing the timestamps, but they should only be changed when /system clock set format= is set to a new value (and it can be defaulted to a ISO standard for new devices too), but it should also have /system clock set format=legacy which keeps every single date and time format the way they were pre v7.10 and any upgrade should always retain the setting of legacy, only new devices or reset devices should default to a new format.
@BrianHiggins you are right,
a worse change than this [:execute], with a bigger impact, had been stopped by complaints in a past beta version of RouterOS,
and had been agreed to insert a parameter, much as I suggested.
@Larsa
what are you referring to?
it’s not clear whether you’re making any allusions or not, so
It’s incredible that a “garage-based company full of hacker heros” is able to control everything that is written inside every single device, every single CPE
and “a serious corporation with a large installation base” not…
Hmm…
Also adopted the change for my scripts already… This now works with old and new format. I am fine to keep it that way. 
BTW, another place to adopt:
[admin@MikroTik] > :put [ /system/resource/get build-time ]
May/09/2023 10:38:53
(unfixed places are listed on top pages)
using the same style, as I would:
:if ([ :pick $Date 4 5 ] != “-”) do={
:local Months { “jan”=1; “feb”=2; “mar”=3; “apr”=4; “may”=5; “jun”=6;
“jul”=7; “aug”=8; “sep”=9; “oct”=10; “nov”=11; “dec”=12 };
:return ({ "year"=[ :tonum [ :pick $Date 7 11 ] ];
"month"=($Months->[ :pick $Date 0 3 ]);
"day"=[ :tonum [ :pick $Date 4 6 ] ] });
}
:if ($Date ~ “…/../..”) do={
:local Months { “an”=1; “eb”=2; “ar”=3; “pr”=4; “ay”=5; un"=6; “ul”=7; “ug”=8; “ep”=9; “ct”=10; “ov”=11; “ec”=12 };
:return ({ "year"=[ :tonum [ :pick $Date 7 11 ] ];
"month"=($Months->[ :pick $Date 1 3 ]);
"day"=[ :tonum [ :pick $Date 4 6 ] ] });
}
That is probably just as string as distributed in the package, not the result of a function that is running on the device itself…
Well… the synchronous :execute uses “as-string” parameter…same logic could apply to date outputs (e.g. an “as-time” to get the unixsec-since-epoch/“time type” from the date things)
Sure. But I think it should change nevertheless.
I guess the date reported in network neighborhood (/ip/neighbor/) is the same?
Yes, it is just the name of the version, which happens to include a date/time (only for v7, in v6 this wasn’t done).
Of course it can be changed when they change their build scripts. Still, that will show the new format date only for new versions, not for neighbors that run older versions.
I think it’s trifles that don’t count.
I don’t think anyone has made scripts that read that date to do anything with it…