Has anyone found a good work-around for the 2038 problem in NetSuite? Basically anytime I create a custom record with a date field on it containing a date on 4/1/2038 or 11/1/2038, NetSuite converts it to 3/31/2038 or 10/31/2028 respectively.

If this were a rollover problem, I think I'd expect wildly different dates instead of just the day before the intended date. To me this looks more like a timezone conversion on the start date.

It's really weird whatever is going on. It also only happens in the year 2038 and only happens in SuiteScript 2.1. SuiteScript 2.0 is fine. That's a good call out on the timezones. I do call format.format to convert the date object into a string before submitting it to the custom record in the map/reduce, so I'll play around with that some more. Thanks, Eric!

Were all the pictured records created at the same(ish) time?

Yeah, all in one map/reduce run.

Ah, yeah that's very strange then; wouldn't necessarily expect the time to change significantly then

share M/R code?

This is the relevant portion - stPeriodStartDate is what I'm submitting in the reduce. When I log it out - it has the correct date of 4/1/2038. I created a support case with NetSuite, so I'll keep you posted, but do let me know if you have any ideas for different ways to pass the data in!

What are

intEffectivePeriodNumber

and

flEffectivePeriodNumber

? If you delete and re-create all these same records, does the same behavior occur at the exact same place in the schedule?

They drive the setting of the period number in the first screenshot I sent over. And yes, default logic of the script is to delete all the custom records and re-create them every time it's run, so it's reproducible.

you look like you have a problem on march and november. which suggests that its daylight savings related instead

Agreed, definitely daylight savings related, but only 2038 and beyond.