BibLaTeX: misc entries in bibliography contain year twice

[SECtim]

@misc bibliography entries that do not contain a month, day, ..., i.e., only a year, are rendered with the year twice (with acmnumeric.bbx). E.g., the following entry

@Misc{rfc9207,
  author       = {zu Selhausen, Karsten Meyer and Fett, Daniel},
  title        = {{OAuth 2.0 Authorization Server Issuer Identification}},
  howpublished = {RFC 9207},
  year         = {2022},
}

is rendered as Karsten Meyer zu Selhausen and Daniel Fett. 2022. OAuth 2.0 Authorization Server Issuer Identification. RFC 9207. (2022)., notice how 2022 is printed twice.

The is due to https://github.com/borisveytsman/acmart/blob/049003167a3d4b78502ced539dfb8eb59aef6ffc/acmnumeric.bbx#L602 and https://github.com/borisveytsman/acmart/blob/049003167a3d4b78502ced539dfb8eb59aef6ffc/acmnumeric.bbx#L620

which is defined (in biblatex/bbx/standard.bbx) as

\newbibmacro*{organization+location+date}{%
  \printlist{location}%
  \iflistundef{organization}
    {\setunit*{\addcomma\space}}
    {\setunit*{\addcolon\space}}%
  \printlist{organization}%
  \setunit*{\addcomma\space}%
  \usebibmacro{date}%
  \newunit}

The definition of the date bibmacro is (similar to the default definition, except for the enclosing parens): https://github.com/borisveytsman/acmart/blob/049003167a3d4b78502ced539dfb8eb59aef6ffc/acmnumeric.bbx#L77

One possible solution is to use the date-ifmonth bibmacro similar to how publisher+location+date is handled: https://github.com/borisveytsman/acmart/blob/049003167a3d4b78502ced539dfb8eb59aef6ffc/acmnumeric.bbx#L203-L209 https://github.com/borisveytsman/acmart/blob/049003167a3d4b78502ced539dfb8eb59aef6ffc/acmnumeric.bbx#L212-L216

[smokhov]

It appears to be a long standing deliberate design decision that's been discussed a number of times: #432 #306 #201 #200 #151

[SECtim]

I see. However, for @misc (and others, like @online, ...), the examples given in the ACM Author Guidelines clearly show that printing the year once (or not at all, if no year is given) is perfectly fine. This is actually discussed in #201 and #263 and I think this should be fixed as it produces entries that are inconsistent with the ACM Author Guidelines.