I have a dummy binding on a shortcut in a folder that provides a dynamic calendar date icon for the associated app.
I have a dummy binding on a shortcut in a folder that provides a dynamic calendar date icon for the associated app.
However, the last time this ran properly was on 5th October. There must have been an alpha release on either 5th or 6th October that broke it.
The problem seems to be that parseInt(n) on a number with a leading zero (such as that returned by $ll_day) now results in NaN. Adding a second parameter of the form parseInt(n, 10) fixes the problem.
Is this intended new behaviour or is it a bug?
]]>« Can someone teach me how to do script? 😂😂 (Previous Post)
D5 Creation
< ![CDATA[
When converting a number from string to int, the radix is something to be aware of.
That’s the second parameter to the parseInt, and that’s why parseInt(“08”,10)=8
However, when no radix is provided this function (and a lot of other ones, this comes from C) uses this:
If the number starts with “0x” the number is read as base 16.
If the number starts with “0” it is read as base 8.
When starting with other digit it is read as base 10.
This is the reason why:
parseInt(“123”)=123
parseInt(“0123”)=83
parseInt(“0x123”)=291
And for that reason:
parseInt(“08”)=NaN (‘8’ is not a valid digit on base 8)
As far as I know, that’s have been the behavior since…always.
I guess it worked before just because the days didn’t started with 0, or were less than “08”. As soon as the day became “08” the script stopped, and tomorrow (“10”) it would have work again.
Your fix is a good one.
]]>
< ![CDATA[
Ah, so the change isn’t to parseInt(), it’s that $ll_day now returns single digit dates with a leading zero.
Thanks very much for the explanation.
Is this an intended change to $ll_day? I don’t mind one way or the other; I’m just curious whether it’s a bug.
]]>
< ![CDATA[
I think it returned a leading 0 in the past too. Can’t confirm it though.
Pierre Hébert​​?
]]>
< ![CDATA[
I confirm the same.
Thank you so much TrianguloY​
]]>
< ![CDATA[
The leading zero has always been there because it was easier to format date this way (and because date formatting date is the intended use of these variables).
The script can’t work two days in a months. I don’t know how it could come unnoticed, my only assumption is that the error message wasn’t displayed as it should, however I checked that the issue can be seen in V12.9.1 too.
]]>
< ![CDATA[
Oh, so it was purely an issue of the script failing to work on invalid octal dates, namely the 8th and 9th of the month?
Yeah, it’s funny that I never noticed that before.
]]>