https://netsuiteprofessionals.com logo
Join Slack
Powered by
When getValue() of a date field, what are we actua...
# suitescript
c
When getValue() of a date field, what are we actually getting? Is it a string representation of the JS date object? "2022-07-29T070000.000Z" (from the logs)
t
its a JS date object
c
So I can wrap that date in moment(), do my processing, then do moment.toDate() to pass it back to the callers
toDate() should pass back an object that can be written to a field
b
logs convert their details to strings, notable using an object's json form for logging
its why you see json objects instead of [object Object] when you log netsuite objects
Date's are converted to iso 8601 for printing
c
I've inherited some code where the dev clearly didn't understand dates. I'm trying to unwrap all of the moment work they did and start it from scratch. I think the best pattern is to moment(getValue()), process date logic, then return moment.toDate()
a
I would recommend to use format format and format parse to handle dates as much as you can or you would find that server/data center dates specially date/time would not be respected…
c
or use n/format instead of moment
b
its not an instead sort of deal
you dont want to use N/format to manipulate dates
its just for parsing
c
I don't know if parsing is required if I can pass a date object straight into moment
b
depends on what you are doing with moment
a
@battk I found that not using format.format(format.parse(new Date)) would give you wrong date time server side…
c
just adding days/months/years/ to dates
reading, modifying, writing
b
doing relative operation s like adding is fine
doing things like setting hours is not
Copy code
format.parse({value: new Date(), type: format.Type.DATETIMETZ})
is useless because its output is the same as
Copy code
format.parse({value: new Date(), type: format.Type.FLOAT})
c
What's the problem with setting hours using moment?
b
only useful in pacific time
c
How so?
a
It would not respect server side settings and would probably return whatever data center time is…
b
its always pacific time
netsuite has standardized all their servers to use pacific as the local time
when you set the hours of a date to 0 or any other number, it uses the timezone of the server
which has no relation to the user's or the company timezone
a
Is this relatively recent @battk ?
b
the pacific thing has been here forever
a
Wow I was dead sure I saw different times from different data centers a few years ago..
c
So what are the gotchas I'm looking out for?
b
understand when the timezone affects an operation
or learn to ignore the problem and use moment timezone
c
Most of my date work is reading dates, changing them and writing them back
I've not had to touch times yet, I usually tell moment to set the time to begginig of day
.startOf('day")
that makes comparisons easy and nothing Ive done yet has needed precision beyond the day
b
.startOf('day") means setting the hours to 0
thats 12 am
and thats a different Date in different timezones
a
@Craig What if you script runs at 11PM(x time zone) you add one day with moment, it would it be tomorrow or the day after tomorrow?
That is the problem you may face…
c
if it runs at 11pm, tomorrow is today(11PM) plus 24 hours
a
Plus 24h according to which time zone?
c
I've not yet wrapped my head around how the zone matters
a
24h according to a wrong time zone would be the day after tomorrow…
c
I can pass in the timzone as per the company setup
a
11 PM in your time zone could be 1 AM of tomorrow in another timezone
c
Wouldn't setting the timezone on the date object fix that?
b
which method would you plan on using
a
Yes and you would need momentz or something like that, moment have a separate module for time zones
c
moment or luxon - whichever methods they have available
I'm still researching
b
the answer is moment timezone
you can use luxon if you polyfill the intl api's, but once you learn what that involves
you understand why the answer is moment timezone
c
So setting the tz with moment, to the same zone as the company settings, mitigates any issues with the timezone
b
depends
a user event script uses the timezone of the user
a map/reduce uses the timezone of the system user, which is the company timezone
c
Good point - this specific example is map/reduce
When I getValue on a date field, I assume that date respects whatever timezone was used to set that field?
a
You can however, read the company settings and get the timezone and use that all the time with moment timezone and that should be enough.
b
either way, the answer is to use User.getPreference
c
for this instance, I don't want the user to decide anything
b
that gets the correct timezone no matter the context
c
commercial agreements state billing dates are pacific time
I don't know how this works with daylight saving either
I guess it doesn't
I want to set the invoice date as 1/1/2022 Pacific - I just need to create that date with moment.
I don't think there's anything else to think about?
b
whats the timezone of the company?
c
Pacific
b
thats pretty much ideal as far as Date's go
c
message has been deleted
b
you can ignore all timezone complications
c
Would be good to understand the timezone complications in general though
AS I work on pleny of accounts in APAC and EMEA too
b
we shall use the usual united states example
there is a 3 hour different between pacific time on the west coast and eastern time on the east coast
a
@Craig A general rule or good standardized development practice specially for big projects and when handling connections or time sensitive information would be to convert everything to UTC and then from there convert it to the right time zone.
b
2022-01-01T000000-05:00 represents the start of day in an Eastern timezone on 1/1/2022
that same date on the pacific timezone is 2021-12-31T210000-08:00
c
If I get a date form NS, add 30 days, then save it. I don't think the timzone will matter..
I need save the date without a time though
I think
b
netsuite treats Date's and DateTime fields differently
c
I'm changing the type of these custom fields to Date
To remove time completely
b
for a Date, it just ignores the time and timezone
notably, when you get its value again, it will be 12 am in whatever timezone the user is using
again, doesnt matter in a map/reduce script
but for a user event script the Date you get would be 1/1/2022 12:00 am, no matter the timezone
c
Unless the m/r script is outside of pacfic time?
b
which is actually a different Date for different timezones
keep in mind that there are 2 timezones that matter
the timezone of the server running the code
and the timezone of the user
c
The user will see the date in their own locale
b
for a Date field, the user will not get localization
c
ok
b
if you set 1/1/2022, then it will always say 1/1/2022
if it was a datetime field that was 1/1/2022 120000 am, it would be a different string for a user in a different timezone
c
I just want to do stuff() to a record if now() === cuscol_date - then add some days on that date for next time
I dont' think timezones will matter for this
a
Well now() will never be equal to another date because you can’t compare date objects
b
timezone doesnt matter for your case since everything is pacific
however in general it does matter
c
Copy code
moment(nsDate).startOf('day').isSame(moment().startOf('day'));
That's the comparison as it stands now
nsDate is pulled from a Date field.
I don't think timezone would matter in any region for that - for this usecase
I can see how this would be an issue if the date was driven by the user rather than the system.
b
the comparison is fine since you only deal in pacific timezones
c
Would it matter if I dealt in another timezone.. but only the system time?
b
if you value you set for nsDate was for another timezone, you would have trouble since the Date objects are only in pacific timezone
c
How would I get this ti work in another region then?
Does that mean all date object will lose the timezone I set on them?
b
a Date object has a timezone
c
And getValue(dateField) will always have the pacific timezone regardless of what the user intended?
b
that timezone is always going to match the server
there is nothing to set it
so you dont really lose that timezone, its always the same
c
it doesn't sound like a problem
I used to use JODA time when I worked on auction systems (Java), I was always able to take the time a user placed a bid, convert to my preferred timezone and save it
then on the way back to the user, I would convert the time from my preferred timezone, to their timezone
b
if you had a Date field, then a date value of 1/1/2022 represents "2022-01-01T080000.000Z", which is "2022-01-01T000000.000-08:00"
this would not work if you wanted an eastern start of day, which represents "2022-01-01T050000.000Z" or "2022-01-01T000000.000-05:00"
the eastern start of day is not the same as the pacific start of day
c
yes
I can't construct a usecase where this matters in my head
b
and the Date you get out of a NetSuite Date field will always represent 12 am Pacific
if you have a contract that says you pay late fees if you dont pay by "2022-01-01T050000.000Z", and you represent that in NetSuite as a Date field set to 01/01/2022, then the Date you get back from NetSuite will actually be "2022-01-01T080000.000Z"
you have given 3 additional hours to pay the contract
c
Is there a technical solution?
If I can't save the users timezone into the field?
Which is what I believe you are saying
b
dont use the Date field, the DateTime is what you want
c
and does DateTime hold the timezone you set?
b
it contains timezone information in the database, but you won't get that in the Date you get in javascript
the Date in javascript will be in the pacific timezone, but will represent the same moment in the other timezone
c
so I just need to parse that time into the users timezone
which I would have saved somewhere
Or make the commercial agreements be in my timzone
and skip the techincal issue all together
The only issue I'm seeing is that NetSuite does not save the DateTime in the preferred timezone, it overwrites it. As long as you know your users timezone, you can take the DateTime from NS and parse it into their timezone, then do your comparisons based on that.
In NetSuite, you're using pacific as your base. You may save 3pm UK but it saves as 3PM pacific
the pacific part is "wrong" but the 3pm bit is 'correct'. As long as you know what timezone to parse that 3pm into
b
huh
a
You are overthinking it, get the datetime from any source and convert it to UTC(as long as the object comes with the timezone info) then convert it to your timezone(your instance preferences timezone) and you are done, that should account for any scenario…
b
that doesnt sound right
a
And you should be able to do that with moment timezone.
c
"2022-06-09T070000.000Z"
Only got as much timezone info as that gives
b
not really
use .toString() on your Date before logging it
c
I think this is a case of, I understand how to work with dates, I don't understand this conversation though
Or I'm missing something
Maybe the latter.
b
the minor spoiler here is that javascript Dates were based on Java dates, which Joda was designed to correct
if you started with Joda, then you are missing the experience of working where you need to pay attention to timezones
there are 2 different approaches to working with Dates, one is to treat it as a string, the other to treat it as unix time (time difference between 000000 UTC on 1 January 1970)
if you treat it as a string, you want to use the setText based approaches
if you treat it as unix time, then you use setValue based approaches I advise the unix time based approach, mostly because strings are trash to manipulate
netsuite does not respect time or timezone for Date fields, it does respect time and timezone for Datetime fields
if you are using a date field, you can ignore the Date that you get from getValue and use getText to generate your own Date
if you are using a datetime field, its ill advised to ignore the Date that you get from getValue, the value you get from getText will changed depending on the timezone, the Date from getValue will not
you can still use getText with the date time field, it just requires you to understand the timezone that the string uses
the code that you shared
Copy code
moment(nsDate).startOf('day').isSame(moment().startOf('day'));
adds stuff that is unneeded
a Date field already represents the start of the day at 12 am, so its basically the same as
Copy code
moment(nsDate).isSame(moment().startOf('day'));
c
Yeah, that can be removed
b
Copy code
moment().startOf('day')
introduces timezone issues with your code
the start of the day for the eastern timezone is not the same as for a Pacific timezone
c
That was already there and the field was DateTime
I changed the field types to Date and removed the startOf
b
Copy code
moment(nsDate).startOf('day').isSame(moment().startOf('day'));
is especially dangerous for a date time field
you still have the same problem that the start of day is in regards to pacific timezone
c
Yeah, that's why I had the questions about NS deals with timezones, I could not figure out why the time was being set to 00:00
Can't see a reason for it in the code
so assume original dev didn't understand
I think there was no issue with it being datetime though
not for the specific usecase
b
you can ignore all problems for your usecase, everything is nicely aligned with pacific time
c
I don't understand how non pacific time will impact it
That's what I need to go away and write lots of test for to enhance my understanding
I don't care what timezone you're in, your payment and invoice is generated 30 days from the last one.
b
use a suitelet when you do your testing so that you can easily change your user's timezone
scheduled/map/reduce will use company timezone, which is usually harder to change
c
All that will happen is that the APAC customers will get their invoice a day late
as they are ahead by one day
so the 22nd for the US is the 23rd for the aussies
47 Views
Open in Slack
PreviousNext
Powered by