Inconsistent behavior?

[thomaswiradikusuma]

Using the example from the main page (https://github.com/date-fns/tz):

const tzDate = new TZDate(2022, 2, 13, "Asia/Singapore");

Will produce 2022-03-13 00:00:00 Singapore time (correct). But if we use a string literal:

const tzDate = new TZDate("2022-03-13 00:00:00", "Asia/Singapore");

The time will be wrong. In Jakarta, which is GMT+7, it will be 1 hour difference. By right, both should produce the same since we're literally feeding the timestamp from the first code.

In other words, these 2 produce different outputs:

	const a = new TZDate(2022, 2, 13, "Asia/Singapore");
	const b = new TZDate("2022-03-13 00:00:00", "Asia/Singapore");

	console.log(a); // Sat Mar 12 2022 23:00:00 GMT+0700 (Western Indonesia Time)
	console.log(b); // Sun Mar 13 2022 00:00:00 GMT+0700 (Western Indonesia Time)

Or am I missing something?

EDIT: My goal is to give it a string timestamp and a timezone and for date-fns to return a string timestamp for another timezone. E.g. "2022-03-13 00:00:00", "Asia/Singapore" -> "2022-03-12 23:00:00" (if I'm in Jakarta). In other words, I want to produce the output of 1st code but using string input.

[fmercille]

There is actually a third case that is just as inconsistent, if you use a string literal with only the date portion and skip the time (which I would assume should default to 00:00:00 in such a case.

Using the following 3 constructor calls:

const a = new TZDate(2022, 2, 13, "Asia/Singapore");
const b = new TZDate("2022-03-13 00:00:00", "Asia/Singapore");
const c = new TZDate("2022-03-13", "Asia/Singapore");

Printing out the objects will result in 3 different times

console.log(a);
// TZDate 2022-03-12T16:00:00.000Z {
//   timeZone: 'Asia/Singapore',
//   internal: 2022-03-13T00:00:00.000Z
// }

console.log(b);
// TZDate 2022-03-13T05:00:00.000Z {
//   timeZone: 'Asia/Singapore',
//   internal: 2022-03-13T13:00:00.000Z
// }

console.log(c);
// TZDate 2022-03-13T00:00:00.000Z {
//   timeZone: 'Asia/Singapore',
//   internal: 2022-03-13T08:00:00.000Z
// }

None of the 3 instances match any of the others, despite the constructors being called with what should logically be the same.