Is anyone else using N/format to get dates into an...
# suitescript
c
Is anyone else using N/format to get dates into an acceptable format for setValue()? I'm using momentjs for date manipulation then casting into a JS date object before writing to a field. How do other people manage dates? (I believe N/format respects the system date format settings)
a
I just did this today
Copy code
const formattedDate = new Date(format.format({
    type: format.Type.DATETIME,
    value: new Date(),
    timezone: format.Timezone.AMERICA_NEW_YORK
  }))

  newLogRecord.setValue('custrecord_log_date', formattedDate)
I needed to wrap the whole formatted date in a new Date()
b
a lot of the time you dont really want it
for example, in Azi's case,
Copy code
new Date()
makes a Date representing the time right now (which will using Pacific time)
Copy code
format.format({
    type: format.Type.DATETIME,
    value: new Date(),
    timezone: format.Timezone.AMERICA_NEW_YORK
  }))
makes a string representing a date time 3 hours in the future (since Eastern time is 3 hours ahead of Pacific)
Copy code
new Date(format.format({
    type: format.Type.DATETIME,
    value: new Date(),
    timezone: format.Timezone.AMERICA_NEW_YORK
  }))
finally, the new Date constructor will attempt to make a Date 3 hours in the future I use the word attempt since the Date constructor isn't good enough to work in different date formats
the code here takes a Date, turns it into a string, then tries to turn it back into a Date
Azi could have just left it as a Date and used
Copy code
newLogRecord.setValue('custrecord_log_date', new Date())
a
@battk I am fairly certain I was getting an error when I was trying that, but I will try that again tomorrow . It definitely was setting the value to server time zone and I wanted New York Time zone
My field was a type of Date/Time so maybe that's why it needed more than just new Date().
b
date time fields respect timezones
the string you get out of it will be different in the pacific vs an eastern timezone
both strings would represent the same unix time if you take the timezone they are shown in into account
you would not want a date time field if you only wanted it to represent a single timezone
a
So I am confused about this. It turns out as you said my code is not setting the timezone or at least is not displaying my local timezone. The timezone settings for my company are New York and the system notes date/ time display as my local timezone. So how come my custom sublist which has a date/time field is displaying as servertime?
b
did you change your code?
a
No. But I am not understanding what I would need to change it to
Remove the timezone part?
b
do you understand what unix time is
a
Yes
b
date time fields essentially work off of unix time
when you are setting a date using text like
Copy code
2022-06-13 22:55
it uses the current user's timezone to determine the unix time
when you use an actual Date object, it doesnt even need the timezone
the Date is already represents unix time
a
So setting the timezone will give actually skew the desired results? Or its just not needed?
b
then, when it displays the date to the user, it takes the unix time and displays it according to the current use's timezone
lets start with the breakdown of your code again
do you know what new Date() does?
a
Yes. Create a date object that represents the current date and time at UTC
b
the timezone is not really important at this point
the Date representing now is the same regardless of the timezone
they all are the same unix time
a
Correct. If there is an offset, that will just display differently but it essentially is the same stamp
Correct?
b
same moment
onto the second part
do you know what
Copy code
format.format({
    type: format.Type.DATETIME,
    value: new Date(),
    timezone: format.Timezone.AMERICA_NEW_YORK
  }))
does
a
So what I assumed was that this formats the current UNIX timestamp with an offset for New York
b
yes, on a more techincal level, it converts the Date into a string, formatted according the the user's date and time preferences
and using the New York Timezone
depends on the settings, but it will be a string like
Copy code
2022-06-13 22:55
now finally, we are onto the last step, do you know how the Date constructor works
a
Ah! So if it is a string representation of that that time and then I am wrapping that in a another new Date() it will create a new timestamp not of the current moment but of the strings moment
b
missing an important distinction
there is no timezone data in that string
its going to assume its Pacific time
which is incorrect, you specifically specified New York
a
I hear what you are saying. That makes sense
b
so the Date's unix time is going to be off by 3 hour
there are other complications, like some date formats won't be parsed correctly by the date constructor
which is why my original description said it was an attempt
it would fail for some date preferences and succeed for others
a
So then shouldn't setting without the whole format with timezone
Copy code
newLogRecord.setValue('custrecord_the_date', new Date())
set the current date and time and then my company setting would adjust how it is displayed to me?
b
user preferences is what determines how its displayed to you
the company preferences influences the user preferences in that it defaults the user preferences
but its pretty common for users to change their timezone
a
So where am I going wrong? This is my user preference
Weird. Now it worked