Unas pocas cosas:

• Su ejemplo de new Date("2022-03-24") hará que la entrada se interprete como medianoche UTC debido al formato que utilizó. Es idéntico a new Date("2022-03-24T00:00:00.000Z") . También obtendría el mismo resultado con new Date(Date.UTC(2022, 2, 24, 0, 0, 0, 0)) .
• Su ejemplo de new Date(2022, 2, 24, 0, 0, 0, 0) tendrá la entrada interpretada como hora local debido al constructor que utilizó. Da el mismo resultado que la new Date("2022-03-24T00:00:00.000") (sin la Z ).
• El objeto Date en sí mismo no tiene zona horaria, es solo un envoltorio alrededor de una marca de tiempo Unix basada en UTC.
• Lo que haga con el objeto Date resultante tiene tanto que ver con si observará una conversión de zona horaria como con su creación. Por ejemplo, toString proporcionará una representación de cadena en términos de hora local, pero toISOString proporcionará una representación de cadena en términos de UTC.
• Por lo tanto, la única forma de evitar por completo cualquier conversión de zona horaria es construir en términos de UTC y luego usar funciones que generen resultados en términos de UTC (como toISOString ) u obtener/establecer en términos de UTC (como getUTCHours , setUTCHours , etc. )
• Usted mencionó que está utilizando un selector de fecha.
  • Muchos selectores de fecha tendrán propiedades que le devolverán un objeto Date , pero algunos le devolverán una cadena en formato aaaa-mm-dd. Si su objetivo es pasar la fecha elegida a una API de back-end, debe evitar usar un objeto Date . Simplemente tome la cadena y envíela en su lugar. El <input type="date"> estándar es un buen ejemplo. Consulte los documentos de su propiedad Value para obtener más detalles.
  • Si su selector de fecha solo proporciona un objeto Date , es probable que se haya construido en términos de la zona horaria local del usuario. Debe crear una cadena de fecha en formato aaaa-mm-dd usted mismo (usando las propiedades basadas en la hora local getFullYear , getMonth y getDate ), y luego pasar eso a su API.