From what I can tell, tenant Time Zone defaulting seems to follow the following hierarchy
if no records defined here, then
if no default time zone defined, then
What is the ultimate fall back default tenant time zone if it is specified in neither of the above locations?
You are correct about the fallback hierarchy. If nothing is defined in either Tenant Environment Setup nor Tenant Management, the system will assume a default time zone of UTC.
The only exception to this is Tenant Data Refresh’s automatic scheduling behavior, which defaults to “US/Central” instead of UTC.
Is there a known issue in setting the default timezone in the Tenant Environment Setup? I was in a production environment and I saw the default timezone is set to EDT; however, if I looked at the Endpoint Logging, the Create Date column is showing my browser timezone (PDT) instead:
DateTimes in Nextworld are always displayed to end users via the UI in their browser time zone, so what you are seeing is expected.
This thread about tenant time zone defaulting mostly matters in logic that consumes a tenant time zone. We however recommend logic that needs to be time zone aware to use an org unit/company time zone for that purpose (but that isn’t the case in all logic everywhere).
If you are in an instance of Nextworld that has west coast and east coast org units/companies in the same instance, and the logic hasn’t been written to use the org unit/comapny time zones, then DateTime ↔ Date conversions are done using a default tenant time per the above hierarchy. If the default tenant time is Eastern Time, then transactions after 9pm in Los Angeles that get stamped with a date will get stamped as having happened the next day. That’s why the attached recommendation from Nextworld Help exists about not using tenant time zone in logic.
This pertains to the formatting of values displayed in the user interface:
The formatting of values shown in the user interface leverages browser APIs where a locale or language tag is part of the input and then the browser creates a locale-specific display presentation for a raw value that matches what it thinks meets that selected locale format. Examples of locales (or language tags) are fr-CA for French Canadian and en-US for United States English. An example could be the raw value 1000.50 where it might be presented as 1 000,50 in French Canadian and 1,000.50 in US English.
Ah, okay. Thanks for the thorough explanations. My customers are dealerships and they want to show the UI date time in dealer timezone (e.g. EDT) even though their users might be using their computers in different timezone (e.g. PDT). So do we need to customize wherever the date/time is shown in UI somehow?
That checkbox has nothing to do with time zones (it only has to do with decorative formatting like spaces, commas, order parts). Dates are stored in the database using ISO 8601 UTC values and we present them to the user using the time zone that the browser tells us that the user is in.
In a date time input field, there is a time zone picker that can be used to help enter a value from another time zone but that is only for aiding data entry and not something persisted.
So do we need to customize wherever the date/time is shown in UI somehow?
I don’t believe something like that is possible via customization. What I think you’re asking for isn’t something that Nextworld is currently capable of as far as I know. We would need to provide a user setting that is something like Display DateTimes in xxx Time Zone and ignore the browser time zone, which I believe is what we use to display DateTimes to the user currently.
Yes, your understanding is absolutely correct. Maybe it could be an enhancement in the future.
