https://netsuiteprofessionals.com logo
Join Slack
Powered by
Hello team, I keep having an issue when assigning ...
# suitescript
a
Hello team, I keep having an issue when assigning dates to NetSuite fields (Date type) from a string in ISO format. I always get the date minus 1 day in NetSuite. So, if I get a string that is “2023-06-05”, and I assign it to a date field in NetSuite (e.g. rec.setValue({fieldId: “custrecord_date”, value: new Date(“”2023-06-05)});), I will get in NetSuite a date of 2023-06-04. Any suggestions on how to avoid this?
r
Dates are getting stored in PST time zone most probably while your preferred timezone is different that's why you are seeing this issue.
a
thanks, yes, that is probably the issue. but how to correct it? @raghav
r
Depends, If PST timezone date is correct then you can change your preferred timezone to post. Else you need to handle the date timezone before setting in the field.
a
I would like to do the latter. How could I do that? I am in Central Europe timezone.
b
2023-06-05
does not include a timezone, so the Date parser is assuming its utc
so your date actually represents 
2023-06-05T00:00:00.000Z
the Date object works in pacific time, so that date is the same as 
2023-06-04T17:00:000-7:00
and now we arrive at why your date is off, you are using the Date constructor incorrectly
the responses about timezone only matter for date time fields
normal date fields dont care about your user's netsuite timezone
a
so, I should add the timezone info to the date constructor, right?
something like “2023-06-05T1900000+2:00”
correct?
for CET
b
depends what you really want your date to represent, even if you got the CET timezone correct, it will be converted to Pacific time at the end
if thats what you want, then your solution is fine
a
if I store it like I mentioned, when I do a rec.getValue() for a user with CET timezone, it should return 2023-06-05, which is what I want
b
as mentioned before, user timezone is irrelelevant for date fields
your proposed solution of adding the time and cet offset sounds like it will work for 15 hours of the day
it would fail for the 9 remaining hours where the conversion to pacific time would make the date off by 1
as an example, 
2023-06-05T19:00:000+2:00
is 
2023-06-05T10:00:000-07:00
which keeps the date correct while 
2023-06-05T08:00:000+2:00
is 
2023-06-04T23:000-07:00
which will be off
a
so, what is the solution then?
b
various ways you can approach this, mostly variations of getting it correct in pacific time
a
ok…
14 Views
Open in Slack
PreviousNext
Powered by