toLocaleDateString() output changed after V8 migration

var d = new Date(Date.UTC(2012, 11, 21, 12));
d.toLocaleDateString();            // Rhino: "December 21, 2012"   V8: "12/21/2012"
d.toLocaleDateString('de-DE', { year: 'numeric', month: 'long', day: 'numeric' });
                                   // Rhino: "December 21, 2012" (args ignored)   V8: "21. Dezember 2012"

Why it happens

Rhino always used the long format and ignored any locale or options you passed. V8 implements the standard Intl behaviour: short format by default, and arguments are honoured. Emails, file names, sheet cells and string comparisons built from these methods all change.

The fix: format explicitly

Utilities.formatDate uses Java SimpleDateFormat patterns and the script's time zone — stable on every runtime:

var tz = Session.getScriptTimeZone();
Utilities.formatDate(d, tz, 'MMMM d, yyyy');        // December 21, 2012  (old Rhino date format)
Utilities.formatDate(d, tz, 'yyyy-MM-dd HH:mm');    // 2012-12-21 07:00

Or, if you want locale output, pass explicit options so the result is deliberate:

d.toLocaleDateString('en-US', { year: 'numeric', month: 'long', day: 'numeric' });

How V8Shift handles it

No-argument toLocaleDateString() calls are rewritten to Utilities.formatDate(…, Session.getScriptTimeZone(), "MMMM d, yyyy") (marked for review). toLocaleString(), toLocaleTimeString() and calls with arguments are flagged as warnings.