I've been asking (and not only me) for this change for years, finally...LONG LIVE ISO 8601 https://xkcd.com/1179/
For backward compatibility, this approach with new variable is the only way forward.If Mikrotik was only a just a bit smarter then they had introduced with new format a new variable containing the new date format.
Someting like: [/system clock get isodate]
So how long do I have to ask for Zerotrust Cloudflare Tunnel in an options package (for all devices).............. ??I've been asking (and not only me) for this change for years, finally...LONG LIVE ISO 8601 https://xkcd.com/1179/
Some years...So how long do I have to ask for Zerotrust Cloudflare Tunnel in an options package (for all devices).............. ??
I've been asking (and not only me) for this change for years, finally...
Since the date format is changed also on LOGs, certificates, etc. and WebFig (and on future I hope Winbox)Someting like: [/system clock get isodate]
/system clock set format=<VALUE>
Except it should have been a type from the real unixsecs...seeLONG LIVE ISO 8601 https://xkcd.com/1179/
:todate [:timestamp]
[/system clock get date "%h %m %s"]
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.format can be yyyy-MM-dd or mmm/dd/yyyy, the default is yyyy-MM-ddCode: Select all/system clock set format=<VALUE>
Added, thanksThe 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
Sorry, my proposal is closer to RouterOS language and is easy manageable instead to add parameters to all points where date can be retrieved. viewtopic.php?t=196061#p1001195
[/system clock get date format="%h %m %s"]
/system clock set format="%YYYY-%MM-%DD-%hh:%mm:%ss"
But quibbling about %'s vs DD seems a bit premature.For me the only valid format should be Unix Epoc everywhere, and if you want to read the date in plain text, convert it.
The change notes said: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?).
[…]
(and probably all other points where can be retrieved one date, like on /log, /certificate, /system scheduler, etc.)
[…]
EDITED:
exception found till now:
/system resource build-time = May/09/2023 10:38:53
from @pe1chl: system,info ntp change time May/10/2023 14:27:56 => May/10/2023 14:27:56
[…]
You're not alone on this planetNO, it's better to "fix" the scripts (very easy) than revert to the previous shitty format
In your suggestion, EVERYONE needs to do something.
NO, it's better to "fix" the scripts (very easy) than revert to the previous shitty format
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.NO, it's better to "fix" the scripts (very easy) than revert to the previous shitty format
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!
what are you referring to?It may not be a significant concern for a garage-based company full of hacker heros
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 CPEbut for a serious corporation with a large installation base, it might have a profound impact
Also adopted the change for my scripts already... This now works with old and new format. I am fine to keep it that way.Just updated some scripts with the autodetect:
[admin@MikroTik] > :put [ /system/resource/get build-time ]
May/09/2023 10:38:53
: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 ] ] }); }
# or on alternative, :if ([:len $date] = 11) do={ :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...BTW, another place to adopt:Code: Select all[admin@MikroTik] > :put [ /system/resource/get build-time ] May/09/2023 10:38:53
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)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.
Sure. But I think it should change nevertheless.That is probably just as string as distributed in the package, not the result of a function that is running on the device itself...BTW, another place to adopt:Code: Select all[admin@MikroTik] > :put [ /system/resource/get build-time ] May/09/2023 10:38:53
I have a cat biscuit for you! (showoff)Come on, it took me a moment to modify all my scripts on the forum and in production to be ready
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.Come on, it took me a moment to modify all my scripts on the forum and in production to be ready
You always manage to give me that point of view that I miss,[…] but more the vast number of copy/paste programmers that have tinkered a script that works and suddenly it breaks when upgrading. […]
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.You always manage to give me that point of view that I miss,[…] but more the vast number of copy/paste programmers that have tinkered a script that works and suddenly it breaks when upgrading. […]
Thank you.
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.
:local arrMonths {jan="01";feb="02";mar="03";apr="04";may="05";jun="06";jul="07";aug="08";sep="09";oct="10";nov="11";dec="12"}
:local today [/system clock get date]
:local dateinside "$[:pick $today 7 11]-$($arrMonths->[:pick $today 1 3])-$[:pick $today 4 6]"
:local backupfile "$[/system identity get name]_$dateinside_$[/system clock get time]_$[/system resource get uptime].backup"
@rextended
Would you revive this for me, please? It doesn't work correctly anymore.
:local isodateonly do={ /system clock :local vdate [get date] :local vdoff [:toarray "0,4,5,7,8,10"] :local MM [:pick $vdate ($vdoff->2) ($vdoff->3)] :local M [:tonum $MM] :if ($vdate ~ ".../../....") do={ :set vdoff [:toarray "7,11,1,3,4,6"] :set M ([:find "xxanebarprayunulugepctovecANEBARPRAYUNULUGEPCTOVEC" [:pick $vdate ($vdoff->2) ($vdoff->3)] -1] / 2) :if ($M>12) do={:set M ($M - 12)} :set MM [:pick (100 + $M) 1 3] } :local yyyy [:pick $vdate ($vdoff->0) ($vdoff->1)] :local dd [:pick $vdate ($vdoff->4) ($vdoff->5)] :return "$yyyy-$MM-$dd" } :local backupfile "$[/system identity get name]_$[$isodateonly]_$[/system clock get time]_$[/system resource get uptime].backup">>> ***********_2023-06-16_21:34:39_1w6d12:05:54.backup
Thank you very much.This work regardless the RouterOS date format
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 <var> <start> [<finish>]. To get my scripts to work I have changed the values in the pick function.@rextended
Would you revive this for me, please? It doesn't work correctly anymore.2023-06-16_21-14-57.jpgCode: Select all:local arrMonths {jan="01";feb="02";mar="03";apr="04";may="05";jun="06";jul="07";aug="08";sep="09";oct="10";nov="11";dec="12"} :local today [/system clock get date] :local dateinside "$[:pick $today 7 11]-$($arrMonths->[:pick $today 1 3])-$[:pick $today 4 6]" :local backupfile "$[/system identity get name]_$dateinside_$[/system clock get time]_$[/system resource get uptime].backup"
################################################################### func_shiftDate - add days to date
# Input: date, days
# date - "jan/1/2017"
# days - number, +/-
################################################################### uncomment for testing
#:local date "jan/01/2100"
#:local days 2560
########################################
#:put "$date + $days"
#use external functions
:local mdays {31;28;31;30;31;30;31;31;30;31;30;31}
: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}
:local monthr {"jan";"feb";"mar";"apr";"may";"jun";"jul";"aug";"sep";"oct";"nov";"dec"}
:local dd [:tonum [:pick $date 4 6]]
:local yy [:tonum [:pick $date 7 11]]
:local month [:pick $date 0 3]
:local mm ($months->$month)
:set dd ($dd+$days)
#:put $dd
:local dm [:pick $mdays ($mm-1)]
:if ($mm=2 && (($yy&3=0 && $yy/100*100 != $yy) || $yy/400*400=$yy) ) do={ :set dm 29 }
:while ($dd>$dm) do={
:set dd ($dd-$dm)
:set mm ($mm+1)
:if ($mm>12) do={
:set mm 1
:set yy ($yy+1)
}
:set dm [:pick $mdays ($mm-1)]
:if ($mm=2 && (($yy&3=0 && $yy/100*100 != $yy) || $yy/400*400=$yy) ) do={ :set dm 29 }
};
:while ($dd<=0) do={
:set mm ($mm-1)
:if ($mm=0) do={
:set mm 12
:set yy ($yy-1)
}
:set dm [:pick $mdays ($mm-1)]
:if ($mm=2 && (($yy&3=0 && $yy/100*100 != $yy) || $yy/400*400=$yy) ) do={ :set dm 29 }
:set dd ($dd+$dm)
};
:local res "$[:pick $monthr ($mm-1)]/"
:if ($dd<10) do={ :set res ($res."0") }
:set $res "$res$dd/$yy"
:return $res
#############################################################################
# Get Yesterday
#######################################################################
:local shiftDate [:parse [/system script get func_date source]]
:local DT ([/system clock get date])
:local LASTDAY [$shiftDate date=$DT days=-1]
:put "TODAY Date = $DT"
:put "YESTERDAY date = $LASTDAY"
###################### Month / Year #################
:local arrMonths {jan="January";feb="February";mar="March";apr="April";may="May";jun="June";jul="July";aug="August";sep="September";oct="October";nov="November";dec="December"}
:local strYear [:pick $LASTDAY 7 11]
:local strMonth ($arrMonths->[ :pick $LASTDAY 0 3 ])
:local strDay [:pick $LASTDAY 4 6]
You always manage to give me that point of view that I miss,[…] but more the vast number of copy/paste programmers that have tinkered a script that works and suddenly it breaks when upgrading. […]
Thank you.
viewtopic.php?t=127050#p1032727if you don't mind, can you review above code & fix it for me. please @rextended
Thanks i removed all previous code & moved to your one. works very well. Thank you againviewtopic.php?t=127050#p1032727if you don't mind, can you review above code & fix it for me. please @rextended
:local date [/system clock get date]
:local day [:pick $date 4 6]
:if ($day = "02") do={
MY SCRIPT
}
Thank you so much! It works now.Instead of :pick $date 4 6, the new date format you do :pick $date 8 10
Instead of blindly copying and pasting, try to understand what that command is for and why it was used that way.Thank you so much! It works now.Instead of :pick $date 4 6, the new date format you do :pick $date 8 10