Date/Time macros should not look for word separators + Clean up date time macro code

[GaurangTandon]

Currently, [[%d(YYMMD)]] does NOT translate to anything. However, technically speaking, there's no reason why it should NOT translate to 170402.

Implement this in next version.

Issue reported by James on support email

[GaurangTandon]

@iWrote Can you think of any use case where this practice may yield unexpected results?

One thing I am sure, is that the date/time macros are not overlapping. Like, there's no macro pair of the sort "alp_ha_" and "_ha_ppy" so implementing the user's request should be a safe job, right?

[GaurangTandon]

I revamped the order of the symbol list, so now it first checks for the biggest symbols (MMMM), and then the smallest (MM). This way we avoid all unexpected consequences of having no word separators.

[GaurangTandon]

In the meanwhile, I must try to resolve the big mess of the nested array i've made my array into. It's in extensible, inflexible, and doesn't auto-update with the list on the options page.

[GaurangTandon]

I do not think the structure is inflexible. However, I concur that a list of objects would be better, with the format:

1. Symbol
2. replacer function
3. date arithmetic change
4. long description (for help page)
5. example text

to result in such a format:

[
    {
        key: "D",
        replacer: function(date){ ... },
        arithmeticChange: 86400,
        description: "insert today's date, padded",
        example: "09"
    },
    {
        ...
    },
    ...
]

Then this list could be used to directly generate the options page macro reference. @JAIDEV123 we would need to integrate this structure with the options page, consider this while making that part of the options page.

[metbril]

I am experiencing something similar. I generate a more or less unique (timestamped) ID for my notes, by using a timestamp

[[%d(YYYYMMDhhm)]]

The last 'm' is not converted to the minutes, but becomes a literal. It will output 2019082609m.

If I insert a space in the snippet like

[[%d(YYYYMMDhh m)]]

then the 'm' is expanded to the minutes. It will output 2019082609 26

[metbril]

In addition to my previous comment, this is also happening if I try to create an ISO 8601 formatted date WITHOUT SECONDS like 2019-08-28T10:32+0200. The macro for this is

[[%d(YYYY-MM-DThh:mz)]]

but it expands to 2019-08-28T10:m+0200, so the 'minutes' are not properly expanded.

If using a space between 'm' and 'z' in the macro, the 'm' is expanded.

If I use the macro for a date INCLUDING SECONDS, the macro

[[%d(YYYY-MM-DThh:m:sz)]]

properly expands to 2019-08-28T10:32:54+0200.

My conclusion: the issue is fixed around the 'm' minutes parameter.

[GaurangTandon]

Thanks, I'll look into this soon @metbril