好的.这有点糟糕，但你知道它会是这样.

Okay. This is a little awful, but you knew it was going to be.

首先，您可以访问(例如)'L'的实际格式字符串:

First, you can access the actual format string for (for instance) 'L':

var formatL = moment.localeData().longDateFormat('L');

接下来，您可以通过明智的正则表达式替换对其进行一些手术:

Next, you can perform some surgery on it with judicious regex replacement:

var formatYearlessL = formatL.replace(/Y/g,'').replace(/^W|W$|WW/,'');

(也就是说:删除YYYY，加上删除后留下的孤立分隔符)

(Which is to say: Remove YYYY, plus the orphaned separator left by its removal)

然后您可以在瞬间格式调用中使用您的新格式字符串:

Then you can use your new format string in a moment format call:

someDate.format(formatYearlessL);

这必然做出一些假设:

• 区域设置的月 + 日数字格式的顺序与该区域设置的年 + 月 + 日格式的顺序匹配，但删除了年份.
• 短格式仅在月和日之间使用分隔符(没有前导/尾随分隔符).
• 短数字日期格式的分隔符始终为非字母数字.
• 格式由数字元素和分隔符组成，而不是带有文章的句子格式(请参阅下面 RGPT 关于西班牙语和葡萄牙语的评论，这也适用于其他一些语言的长格式).

快速回顾一下 locale/*.js，这些假设适用于我检查的每个语言环境文件，但可能存在一些违反它们的语言环境.(ETA:下面的评论指出德国短日期格式违反了第二个假设)

On a quick review of locale/*.js, these assumptions hold true for every locale file I examined, but there may be some locales that violate them. (ETA: a comment below points out that a German short date format violates the second assumption)

另外一个重要的警告是，这很可能是脆弱的.完全有可能moment.js的未来版本会改变当前在longDateFormat中的数据位置...

As an additional important caveat, this is likely to be fragile. It is entirely possible that a future version of moment.js will change the location of the data currently in longDateFormat...