Time offset
Last updated
Was this helpful?
Last updated
Was this helpful?
In the portal, local time conversion can be switched on or off.
By default, the local time conversion is switched on. This means the portal will be sending and expecting to receive UTC (Coordinated Universal Time) as the time standard.
The date/time from the database will be converted according to the locale settings in the user's browser. If a user is in timezone +2, two hours will be added to the database time
Any adjustments due to server locations and settings of connecting systems must be handled in the workflows.
The portal will not adjust the date/time when sending or receiving. This means the time selected in for example the scheduler portlet is what is sent to the server and browser settings will not affect the date/time displayed in the portlet.
This setting is recommended if other systems reading and writing to the same data source are not UTC aware
Time formats are often written as lettered abbreviations. For example, YYYY would mean four character year indication - 2020 or 2030 for example.
Then adding months and days with a dash as a separator would be YYYY-MM-DD. May the 4th of the year 2030 would in this case be 2030-05-04. This is also the for dates, going from large (year) to small (day) (general-to-specific) and days and moths are two characters always (02, not 2, for February). This is commonly not the case in Europe and the U.S. since the day and month part can come first, depending on the country it is day or month first. So 4/5/2030 could be May 4th in one country and 5th of April in another and no way to tell which.
To solve this issue most computer-based systems tend to use YYYY-MM-DD as a default display of dates, and then let the front end adjust that accordingly (typically a setting on the user or the user's company in the ERP).
Deep internally the date is likely stored as a number value (for faster math operations) with the numbers of dates since a certain year, followed by the fragments of a day (continuing from large to small: hours and minutes, etc, possibly down to nanoseconds depending on the data type). But this is taken care of before the date is presented to us in YYYY-MM-DD format so as to be disregarded in this case
When agreed on that it is high to low, and dash as the separator for the date. But there can be either a space separating the date and time or a "T". So both "2030-01-01 01:00:00" and "2030-01-01T01:00:00" are valid. Then some data types include lesser values than seconds, breaking it up with a dot. "2030-01-01 01:00:00.1001" is 1001 milliseconds after 1 am on January 1st in the year 2030.
Flow portal accepts for this reason some different time formats, some examples being: 2030-01-01T01:00:00Z 2030-01-01 01:00:00 2030-01-01 01:00:00.000000 2030-01-0 01:00:00.00 2030-01-01 2030-01-0 01:00