You can solve this problem by using the intl polyfill module to completely replace NodeJS’s implementation of intl.

First run npm i --save intl

Then you need to replace Intl by polyfill:

Intl = require("intl")

That's it. Now you can try:

const date = new Date();
const options = {
        year: 'numeric',
        day: 'numeric',
        month: 'numeric',
        hour: 'numeric',
        minute: 'numeric'
    };
const dateFormatted = new Intl.DateTimeFormat('pt-BR', options).format(date);
console.log(dateFormatted);

// expected output: 24/09/2019 17:43

This will work if you set hour12 property to false. i.e.

Intl.DateTimeFormat('en-US', {
    weekday: 'long',
    year: 'numeric',
    month: 'long',
    day: '2-digit',
    hour: '2-digit',
    minute: '2-digit',
    second: '2-digit',
    hour12: false     // setting 24 hour format 
}).format(807959700000);

It works for both 2am and also 2pm(14hr). But I know the same should work for 12 hour format too, but it is not. I checked in both chrome and firefox browsers.

When I checked the specs, it has defined an algorithm which can be used to implement Intl.DateTimeFormat functionality. I saw there were many special cases handled when hour12 property to set true, and one of the last step is

8. If dateTimeFormat has an internal property [[hour12]] whose value is true, then
   • If pm is true, then let fv be an implementation and locale dependent String value representing “post meridiem”; else let fv be an implementation and locale dependent String value representing “ante meridiem”.
   • Replace the substring of result that consists of "{ampm}", with fv.

So I think, the Intl.DateTimeFormat initially works with date object, later at step(8), it applies this step to put am/pm information.

During this step, may be 2-digits information specified in Intl.DateTimeFormat is not considered, but it has to be. I think this is a valid bug and it is already raised https://code.google.com/p/chromium/issues/detail?id=527926.

PS: I'm not saying issue is in specs, as described in the ECMAScript Language Specification,

Algorithms are used to precisely specify the required semantics of ECMAScript constructs, but are not intended to imply the use of any specific implementation technique.

The time zone is used to calculate the local time:

const timeZones = [
    "GMT",
    "Europe/Madrid",
    "Asia/Tokyo"
];
const timestamp = new Date();
let displayDate;
for (timeZone of timeZones) {
    displayDate = Intl.DateTimeFormat('en-GB', {
        hour: 'numeric',
        minute: 'numeric',
        second: 'numeric',
        timeZone: timeZone
    }).format(timestamp);
    console.log("%s @ %s", displayDate, timeZone);
}

If omitted altogether, it will default to current local time zone in the JavaScript runtime where the code runs:

let displayDate = Intl.DateTimeFormat('en-GB', {
    hour: 'numeric',
    minute: 'numeric',
    second: 'numeric'
}).format(new Date());
console.log(displayDate);

So the property can be used to make it explicit/static or to be able to use other time zones.

Problem: Variable has too broad of a type

What you are experiencing here is a common problem when dealing with functions that require string literal types in their arguments. It's nothing specific to Intl.DateTimeFormat. You can read the docs on Literal Inference for more info.

Let's take a look at what your error is telling you:

Argument of type '{ year: string; month: string; day: string; weekday: string; }' is not assignable to parameter of type 'DateTimeFormatOptions'.

Types of property 'weekday' are incompatible.

Type 'string' is not assignable to type '"short" | "long" | "narrow"'.ts(2345)

The type of your option.weekday is inferred as string. This is not specific enough for the Intl.DateTimeFormat constructor, which only allows three possible string literal values: "short" | "long" | "narrow".

The value of your option variable is fine. But TypeScript only looks at types, not values.

When you write your assignment statement like this:

const option = {
    year: "numeric",
    month: "short",
    day: "numeric",
    weekday: "long",
}

TypeScript infers the type as:

const option: {
    year: string;
    month: string;
    day: string;
    weekday: string;
}

We need to create your variable in a way that will give it a narrower type.

Solution 1: Declare the type

We know from your error that the type which your option variable needs to fit is Intl.DateTimeFormatOptions. We can use that type when you create the option variable.

const option: Intl.DateTimeFormatOptions = {
    year: "numeric",
    month: "short",
    day: "numeric",
    weekday: "long",
}

TypeScript will check each of the properties of your object to make sure that they are assignable to the constraints of the Intl.DateTimeFormatOptions type.

If you provide an invalid value, like this:

const option: Intl.DateTimeFormatOptions = {
    weekday: "numeric",
}

You'll see a red underline on the weekday property. I prefer this approach for that reason -- it is easier to see exactly where the problems are. For weekday: "numeric" your error message would be:

Type '"numeric"' is not assignable to type '"long" | "short" | "narrow" | undefined'

Solution 2: as const

You can change the way that TypeScript infers the type by using an as const statement when you create your variable. This tells TypeScript to treat all properties of your object as their literal types (explained here).

const option = {
    year: "numeric",
    month: "short",
    day: "numeric",
    weekday: "long",
} as const;

TypeScript infers the type as:

const option: {
    readonly year: "numeric";
    readonly month: "short";
    readonly day: "numeric";
    readonly weekday: "long";
}

Each property has a string literal type like "long" rather than just string.

Assuming that your values are valid, these literal types will be assignable to the broader Intl.DateTimeFormatOptions type. For example, "long" is assignable to the union type '"short" | "long" | "narrow"' on the weekday property.

This is very close to being off–topic as opinion based, but here goes anyway.

Which one of these should I use?

Date.prototype.toLocaleString was originally solely implementation dependent and varied quite a bit across browsers. When support for the Intl object was added (ECMAScript 2015, ed 6) then toLocaleString was allowed to support the same options. While support isn't mandated by ECMA-262, probably all current implementations support it.

Note that this did not remove the allowed implementation variability, it just provided some formatting options based on language, region and dialect (and also timezone options based on the IANA time zone database identifiers and values).

The Intl object (and hence toLocaleString) is based on ECMA-402, which doesn't strictly specify formatting, so there is still some room for implementations to differ. The biggest differences are in regard to timezone names (for which there is no standard) and placement of commas, spaces, etc.

However, for most practical purposes, whether you use the Intl object or toLocaleString is up to you, I don't think there's any technical reason to prefer one over the other. While the results for both should be identical for a particular implementation, don't expect the resulting string to be exactly identical across implementations or to conform to a particular format for a given BCP 47 language tag.