To the best of my research, trandate on a transaction like a Sales Order is just a date. In the XML it shows <trandate>29-Jan-2025</trandate>. I'm in Australia, and when using N/search in Suitescript, a filter of ["trandate", "on", "29-Jan-2025"] will not match this, it matches the previous day! This also applies to operators like onorbefore.
So it seems that if you're in another timezone east of UTC, you have to offset all date parameters by -1. I think if you're in the US timezone you never have this problem which is why it's not commonly discussed? I'd love to find some docs which explain this properly and perhaps try to justify it.
So my question is: what is the timezone safe way to filter by date using the search methods in N/search?
To the best of my research, trandate on a transaction like a Sales Order is just a date. In the XML it shows <trandate>29-Jan-2025</trandate>. I'm in Australia, and when using N/search in Suitescript, a filter of ["trandate", "on", "29-Jan-2025"] will not match this, it matches the previous day! This also applies to operators like onorbefore.
So it seems that if you're in another timezone east of UTC, you have to offset all date parameters by -1. I think if you're in the US timezone you never have this problem which is why it's not commonly discussed? I'd love to find some docs which explain this properly and perhaps try to justify it.
So my question is: what is the timezone safe way to filter by date using the search methods in N/search?
I reckon that the behavior you're observing will depend on the type of script you're executing.
Server-side scripts will return the date based on the time zone of your NetSuite account's data center (I assume it's Pacific with DST) . This means the output is consistent and does not change based on where you're accessing it from.
In contrast, client-side scripts (which run in the browser) will provide the date according to the time zone set on your local machine. This can lead to variations in the output depending on the user's location.
