I have a RESTlet and struggle with the Time Zone. It takes the date as PDT which is 7 hours behind. I know the time zone can be set on user level for some script contexts. But I’m not sure as of why I get the time zone that I do. I’ve pushed the time to be correct in SuiteScript, but it’s not a solution that I think is the best. It still logs it as GMT-0700 PDT

trandate: Fri Oct 13 2023 00:00:00 GMT-0700 (PDT)

const date = new Date(extractedValue)
const dateValue = format.parse({ value: format.format({ value: new Date(date.getTime() + (7 * 3600000)), type: format.Type.DATE }), type: format.Type.DATE })
log.debug('DATE VALUE', `${key}: ${dateValue}`)
rec.setValue({ fieldId: key, value: dateValue })

lets start here

const date = new Date(extractedValue)

But how can I get it in a different timezone?

sorta depends on what the extractedValue is

“date”: “2023-10-13",

date fields in netsuite dont care about timezone so you are doing a lot of conversion for a field that doesnt care

I’ve tried to do

const dateValue = format.parse({ value: format.format({ value: new Date(extractedValue), type: format.Type.DATE, timezone: format.Timezone.EUROPE_KIEV }), type: format.Type.DATE, timezone: format.Timezone.EUROPE_KIEV })

But I still get PDT

you will not get very far until you learn that your Date will always be pacific time, it will always print in pacific time

const date = new Date(extractedValue)

log.debug(‘date’, date) = “2023-10-13T000000.000Z” log.debug(‘DATE VALUE’,

${key}: ${date}

) = trandate: Thu Oct 12 2023 170000 GMT-0700 (PDT)

you can use toUTCString or toISOString if you wanted it to print in gmt time

I was just curious

start with a input where the timezone actually matters

But the issue is though that the value that gets set on the record is one day behind, which is the problem even without the format.parse

I think what you're saying is the date is starting life as midnight in one time zone and being converted to PDT which is moving it back 7 hours to the day before.

Yes

So when you get trandate it's coming back with the time data too? Or is it that you're creating a new Date using trandate and it's using your local timezone as GMT and then when it's saved NS is converting it? You should probably stop making a date object out of it to start with if that's the issue since that's causing you grief I suspect.

I only recieve the trandate as 2023-10-13, the new Date() adds time and sets it back 7 hours

Why are you creating a date object from it, do you need to manipulate it?

But if I don’t make it into a Date object i get an error?

i think you need to use format.parse

const dateValue = format.parse({ value: extractedValue, type: format.Type.DATE })

This gave me the error

That the format was wrong i.e. should be DD.MM.YYYY ?

yes

format.parse would be an option if the datetime string was in the user's date format

I had a similar problem in an integration with Stripe. Receiving a JSON datetime of midnight UTC was getting converted to the previous day for all the reasons mentioned above. Because NetSuite's date fields don't care about time, I just forced the incoming timestamp to be the end of the day before making it a Date:

function _asTimestamp(datetime) {
  const endOfDay = datetime.replace('0:00:00', '23:59:59');
  return new Date(`${endOfDay}Z`).getTime();
}
// _asTimestamp('2023-10-03T0:00:00') => 1696377599000

normally the solution of adding time like

new Date(date.getTime() + (7 * 3600000))

works (although you will want to use a number greater than 7 hours when standard time comes around)

I think a better solution is to set the time to midday if you don't care about the time rather than adding a set number of hours. then if the clocks change nobody cares. (appreciate not applicable for all cases depends where in the world you are) get your date object and use .setHours(12,0,0) ; //<--hours/mins/seconds

not good enough @NElliott, try it on

new Date('2023-10-13')

And? Still starts life at midday before NS mangles it and takes off 7 hours?

if you are testing on the console, the local timezone needs to be in a negative utc offset

Right the

new Date()

part is what's going to take off 7 hours; so the 7 (or 8 or whatever offset) will be removed before you could

setHours()

on it

I see now my mistake. In reality I mentioned it because an external system was sending me a date that was 000000 and I asked them to set it to 120000 since NS altered it when I tried to work with it. Slightly different scenario, my bad. 😑