This topic contains 3 replies, has 0 voices, and was last updated by savethepennies 7 years ago.

  • Author
    Posts
  • #8434 Score: 0

    savethepennies
    • Contributions: 0
    • Level 1

    Seems like a basic question but I can’t find anything documented in help or in this forum. Datetimes returned through an ODBC query are in UTC. I need to be able to convert those to local time so that reports produced match what is displayed within the NetSuite UI. So far the functions I would normally use don’t seem to be supported through Connect. Is there a recommended/supported method for that conversion?
    This is a cached copy. Click here to see the original post.

  • #8435 Score: 0

    savethepennies
    • Contributions: 0
    • Level 1

    Apparently not as basic a question as I was hoping. Any ideas?

  • #8436 Score: 0

    chanarbon
    • Contributions: 0
    • Level 1

    Hi savethepennies

    The solution for the conversion if you want to proceed with the conversion of timezone using SQL is the use of the use of SWITCHOFFSET from the result of the query to NS ODBC. This means that the conversion is done after the results has been returned by NetSuite. Although the SQL approach for timezone conversion is only for SQL Server Linked Server. I need to reiterate what I have mentioned the conversion is done after you have retrieved the data from NetSuite.

    The easier approach is just perform the conversion using another code e.g. Java which will read through the results from NetSuite’s ODBC

  • #8437 Score: 0

    savethepennies
    • Contributions: 0
    • Level 1

    I appreciate the response and yes, the conversion would be on the retrieval end. What you have suggested requires an additional platform and limits the ability to report on live data. I’m trying to connect reporting tools to the ODBC directly. Is there really no way to do this with SQL supported by Connect? Even a way of querying the current offset so I can manually adjust?

    There are more limitations I’m working through today that are making datetime values a pain to work with in the ODBC.

You must be logged in to reply to this topic.