0

A web request gives me '2022-03-01'.

I know that is and always will mean UTC 2022-03-01 at midnight exactly.

I need to copy that value onto another CRM date field on the Form

I tried:

var passDateToLib = Date('2022-03-01')
formContext.getAttribute("new_otherdatefield").setValue(passDateToLib)

That new_otherdatefield field is also configured to be a UTC Date only field.

But what ends up shown in the field, is 1 date BEFORE '2022-03-01'. So I suspect it's ignoring the timezone aspect of the Date...

Don Cheadle
  • 5,224
  • 5
  • 39
  • 54
  • 3
    is this what you are after? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/UTC – Jerry Jeremiah Mar 14 '22 at 22:27
  • 2
    _"But when I do new Date('2022-03-01')"_... that will create a `Date` instance set to `2022-03-01T00:00:00.000Z` so that is indeed a UTC representation. What makes you think it's converted to a local time? – Phil Mar 14 '22 at 22:28
  • @JerryJeremiah I'll take a look, but FYI that looks to only accept listed numbers as params, doesn't take a '2022-03-01' for example. Going that route I'll need to parse out my date string and get the year, month, day. If I'm understanding your suggestion properly. – Don Cheadle Mar 14 '22 at 22:30
  • `new Date('March 1, 2022 00:00:00 GMT-0:00')` ? – Mister Jojo Mar 14 '22 at 22:31
  • 1
    @MisterJojo just no – Phil Mar 14 '22 at 22:32
  • @Phil Oh you're right, [I misremembered](https://stackoverflow.com/q/51715259/1048572), it's date-time strings where timezone inference is spotty, date strings always work. OP's real problem appears not to be the parsing but understanding the `toString`/`toUTCString` difference – Bergi Mar 14 '22 at 22:43
  • 2
    This is definitely an [XY Problem](https://xyproblem.info/). By using `new Date('2022-03-01')`, you already have a UTC representation. The real question is, how are you using that `Date` instance? How are you passing it to this _library_? – Phil Mar 14 '22 at 22:46
  • 1
    @DonCheadle "*a library, which is also expecting strictly only a Date that would be interpreted as UTC*" - that seems to be where you're wrong. The library does use the system timezone representation of the date object, not the UTC representation. – Bergi Mar 14 '22 at 22:46
  • appreciate everyone's help, I fear this question is a mess at this point and I might just to delete and re-create a more specific one. I edited it a bunch to be more specific about what's going on. Thanks either way – Don Cheadle Mar 14 '22 at 23:08
  • BTW, dates in the format YYYY-MM-DD **should** be treated as local, it is only ECMAScript that parses them as UTC. Also, the timestamp produced by *toString* represents the exact same moment in time, but only if you don't truncate the time and offset part. – RobG Mar 14 '22 at 23:50
  • 1
    Why are you converting to a Date object at all? Just pass the string. – RobG Mar 14 '22 at 23:53

1 Answers1

0

toISOString() gives the time in ISO format. To get the date only as you mentioned we can use substring method to remove the time. This will basically give the date based on GMT and not for your Local TimeZone.

new Date().toISOString().substring(0,10);

Vishal Tripathi
  • 40
  • 3
  • You seem to be missing the part where OP needs to parse an ISO 8601 date string – Phil Mar 14 '22 at 22:44
  • There is no "GMT format", perhaps you mean ISO 8601 format (hence *toISOString*). ;-) – RobG Mar 14 '22 at 23:48
  • @Phil The date that we will get is already in ISO Format. Also, RobG thanks for the correction here as date received is in ISO Format. – Vishal Tripathi Mar 15 '22 at 04:44