If your dates for Dec 30 and 31 have the wrong year, this is Y

The ICUDateTime et al tokens use the ICU Core formatting, and it has two possible year tokens.

You should generally be using y (lowercase) which has the very simple description of year.

But if you are inadvertently using a capital Y, then it has this very complex description:

year in “Week of Year” based calendars in which the year transition occurs on a week boundary; may differ from calendar year ‘y’ near a year transition. This year designation is used with pattern character ‘w’ in the ISO 8601 year-week calendar, for example.

The two are the same except for a few days near the transition of the year. For this year, that’s Dec 30 and 31.

So if you suddenly start seeing Dec 2025 dates, that is probably the reason.

Have a Happy New Year by avoiding this issue!

10 Likes

When this subject was mentioned in the solution to a question here the other day, I started looking into what "week of year" calendars were and it all got a little too deep…

Since most users (other than accountants?) will only use y date tokens, perhaps a future version of the Editor could display one of Keyboard Maestro's helpful warnings :warning: when Y is used.

The problem with that is there is no way to turn off such warnings in cases where they are ok.

Yes, but is that really a problem?

  • My quick look into what a "week of year" calendar was gave me the impression that only a small fraction of KM users would use Y deliberately.[1]
  • Action warnings have been implemented perfectly; they catch the eye but are not a distraction.
  • I do not recall any complaints about the alert in the Search and Replace action when an asterisk is used under the default string setting, and I would expect the deliberate use of * outside a regex string[2] to be more common that the deliberate use of Y.

  1. e.g. "It is used (mainly) in government and business for fiscal years, as well as in timekeeping" – ISO week date - Wikipedia ↩︎

  2. e.g. "… see the footnote below.* …" ↩︎

1 Like

There is a more technical problem - tokens do not have error modes - tokens already produce a result (even if it is nothing, or just the plain text unmodified). And tokes appear everywhere through Keyboard Maestro. So the technicalities of providing this error information within every action are non-trivial, which makes it hard to justify for an outlier case like this.

1 Like