JavaScript Date object is actually worse than I thought

So a few years ago I was complaining about some weird behavior I discovered in the JavaScript Date object. In particular, that new Javascript('2018-01-01') creates an object at GMT/UTC 0. Which is fine, except that the .getFullYear() method gets a value localized to my current time zone, which leads to unexpected results when my date is different than GMT-0.

I was just playing around with this again, and discovered that whether Date creates a localized object or not depends on the format of the value passed to the constructor:

new Date('2018-01-01')
Date Sun Dec 31 2017 17:00:00 GMT-0700 (Mountain Standard Time)
new Date('January 1, 2018')
Date Mon Jan 01 2018 00:00:00 GMT-0700 (Mountain Standard Time)

So yeah, kinda awful.

kilo: The horrible, no good, very bad quit confirmation

Step 115 implements a quit confirmation. That is, the user is prevented from quitting kilo while there are unsaved changes, Well, at first:

    case CTRL_KEY('q'):
      if (E.dirty && quit_times > 0) {
        editorSetStatusMessage("WARNING!!! File has unsaved changes. "
          "Press Ctrl-Q %d more times to quit.", quit_times);
        quit_times--;
        return;
      }

Yeah, that's pretty awful UX right there. Ironically, we're just a few steps away from implementing an editorPrompt function (used to prompt for a filename to save to) which could also be used for saying "You have unsaved changes, really quit? (N/y)", which is how virtually every "real" editor does it.