Merge pull request #5749 from newrelic/Change-timezone-in-UI

Add ability for AUM-added users to set their own time zone in NR

src/content/docs/accounts/accounts-billing/general-account-settings/default-time-zone-setting.mdx

@@ -1,7 +1,6 @@
 ---
-title: Default time zone setting
+title: Set your time zone
 tags:
-  - Accounts
   - Accounts and billing
   - General account settings
 metaDescription: How to change the default date/time displayed in the New Relic UI.
@@ -18,18 +17,20 @@ redirects:
   - /docs/accounts/install-new-relic/account-setup/change-your-account-time-zone-setting
 ---
 
-Your personal timezone setting controls most time-related settings in the New Relic UI, with a few exceptions, as explained in this document. If you change your timezone setting, this may take up to 24 hours to be reflected in the UI.
+Your personal time zone setting controls most time-related settings in the New Relic UI, with a few exceptions. 
 
 ## Change your default time zone [#exceptions]
 
 To change your default time zone for your New Relic account:
 
 1. Go to **[one.newrelic.com](https://one.newrelic.com)**.
 2. Select the [account dropdown](/docs/accounts-partnerships/education/getting-started-new-relic/glossary#account-dropdown), then select **User preferences**.
+3. Change your time zone. 
+4. Optional: If you're a user managed via [automated user management](/docs/accounts/accounts/automated-user-management/automated-user-provisioning-single-sign), you're able to toggle using your identity provider's time zone. 
 
-## Exceptions [#exceptions]
+When you change your time zone, this can take up to 24 hours to be reflected in the UI.
 
-Users managed via [automated user management](/docs/accounts/accounts/automated-user-management/automated-user-provisioning-single-sign) can't change their time zone in the UI. That must be configured in your identity provider.   
+## Exceptions where your time zone doesn't apply [#exceptions]
 
 Some New Relic features do not rely on the **User preferences** time zone settings. The following use Coordinated Universal Time (UTC) and aren't affected by user preferences:
 

src/content/docs/accounts/accounts/automated-user-management/automated-user-provisioning-single-sign.mdx

@@ -1,10 +1,10 @@
 ---
-title: Introduction to automated user management and single-sign on (SSO)
+title: "Introduction to automated user management (SCIM provisioning)"
 tags:
   - Accounts
   - Accounts and billing
   - Automated user management
-metaDescription: "How to implement New Relic's automatic user provisioning and management, which supports OneLogin, Okta, and Azure AD."
+metaDescription: "Intro to New Relic's automatic user management: support for SCIM provisioning for OneLogin, Okta, Azure AD, and more."
 redirects:
   - /docs/guide-scim-sso-configuration
   - /docs/onelogin-scim-sso-app
@@ -21,7 +21,7 @@ Before reading the benefits of automated user management, we recommend reading [
 Benefits of enabling automated user management include: 
 
 * Time and cost efficiency: When you make changes in your identity provider, such as creating, updating, and removing users, these changes are automatically reflected in New Relic. By being able to manage a large set of users from your identity provider, it reduces the workload of your admins who'd otherwise need to do a significant amount of work in New Relic to accomplish the same thing. 
-* Increased productivity: By having a more automatic way to set up users and groups, they're enabled and ready to use New Relic more quickly.
+* Increased productivity: By having a more automatic way to set up users and groups, they're enabled and ready to use New Relic more quickly. 
 * Enhanced security: SCIM is an industry standard protocol for maintaining groups of users. 
 * Use of this feature requires SAML SSO, so once your users are added to New Relic, they can log in using your identity provider. 
 * Popular identity providers Azure AD, Okta, and OneLogin have dedicated New Relic apps, improving ease of enablement. 
@@ -34,14 +34,14 @@ Requirements and recommendations:
 * Supports SAML 2.0 standard for single sign on (SSO).
 * Supports SCIM 2.0 standard.
 * [User model](/docs/accounts/original-accounts-billing/original-users-roles/overview-user-models)-related requirements:
-  * This feature requires you to be on our [New Relic One user model](/docs/accounts/original-accounts-billing/original-users-roles/overview-user-models) and creates users on that model. If you're on our [original user model](/docs/accounts/original-accounts-billing/original-users-roles/overview-user-models) (or otherwise can't implement this feature), talk to your New Relic account representative.
-  * Configuration requires that a user have the [**Authentication domain manager** and the **Organization manager** role](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts/#roles) (users in the [default group **Admin**](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts/#default-groups) have these).
+  * This feature requires you to be on our [New Relic One user model](/docs/accounts/original-accounts-billing/original-users-roles/overview-user-models) and creates users on that model. If you're on our [original user model](/docs/accounts/original-accounts-billing/original-users-roles/overview-user-models), talk to your New Relic account representative.
+  * Configuration requires the [**Authentication domain manager** role](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts/#roles) (users in the [default group **Admin**](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts/#default-groups) have this).
 * There are three identity providers that have a New Relic app: Azure AD, Okta, and OneLogin. For other identity providers, you can use our [SCIM API](/docs/accounts/accounts/automated-user-management/scim-support-automated-user-management).
 * Before enabling this, it helps to first set up [user groups](/docs/accounts/accounts/automated-user-management/roles-permissions-automated-user-management) in your identity provider service and think about which New Relic roles and accounts those groups will have access to. 
 
 ## Set up automated user management [#how-to]
 
-For an explanation of how your identity provider groups map over to New Relic groups, see [Group and role mapping](/docs/accounts/accounts/automated-user-management/roles-permissions-automated-user-management).
+For an explanation of how your identity provider groups map over to New Relic groups, see [How your groups map over](/docs/accounts/accounts/automated-user-management/roles-permissions-automated-user-management).
 
 To use automated user management to import users from your identity provider:
 
@@ -51,7 +51,7 @@ To use automated user management to import users from your identity provider:
 4. If you **don't** use one of the above services, you'll need to:
   * Use the authentication domain UI to [enable SCIM as the source of users](/docs/accounts/accounts-billing/new-relic-one-user-management/authentication-domains-saml-sso-scim-more/#source-users). 
   * Use our [SCIM API](/docs/accounts/accounts/automated-user-management/scim-support-automated-user-management) to integrate with your identity provider service. See [the SCIM API tutorial](/docs/accounts/accounts/automated-user-management/tutorial-manage-users-groups-scim) for all the steps involved. 
-5. **Highly recommended**: Set a time zone for your users in your identity provider. How you do this will vary by identity provider. If not set in your identity provider, our UI shows UTC time zone dates/times. Time zone is specified in IANA Time Zone database format, also known as the "Olson" time zone database format (for example, "America/Los_Angeles").
+5. **Recommended**: Set a time zone in your identity provider. How this is done depends on the service you use. If you don't set a time zone, our UI uses UTC time zone (specified in IANA format, aka the "Olson" format: for example, "America/Los_Angeles"). Your users also have an option to override your settings and [set their own time zone](/docs/accounts/accounts-billing/general-account-settings/default-time-zone-setting). 
 
 If you have issues, contact your account representative.
 

src/content/docs/accounts/accounts/automated-user-management/azure-ad-scimsso-application-configuration.mdx

@@ -83,7 +83,6 @@ If you're adding users to New Relic via SCIM but **not** managing their [user ty
 * Use the [User management UI](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-ui-and-tasks#edit-user-type) to edit users. 
 * [Configure the Azure app to manage user type.](/docs/accounts/accounts-billing/new-relic-one-user-management/authentication-domains-saml-sso-scim-more/#manage-user-type-scim)  
 
-
 ## Step 6. Assign access grants [#assign-users]
 
 Once these steps are completed, you should be able to see your users in New Relic by going to the [User management UI](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-ui-and-tasks#where). Now that your users are present in New Relic, you must grant them access to specific roles on specific accounts. If this is not done, your users don't yet have access to New Relic. To learn how to do this, see: 

src/content/docs/accounts/accounts/automated-user-management/okta-scimsso-application-configuration.mdx

@@ -62,7 +62,7 @@ Next, you'll assign users. Assigning users is done using two different tabs in t
 2. From the **Assignments** form, click on **Assign**.
 3. From the pop up menu, click on **Assign to groups**.
 4. From the **Assign ... to groups** form, click on **Assign** for the group you wish to assign to the application.
-5. **Highly recommended**: Set your users' time zones in Okta. The time zone affects how date/times for that user are shown in New Relic. Users without a time zone configured will be shown in UTC time in New Relic. Time zone is specified in IANA Time Zone database format, also known as the "Olson" time zone database format (for example, "America/Los_Angeles"). There are several ways in Okta to assign users' time zone, so consult the Okta docs for more information if needed. Here is one way to do this in the **Assignments** tab: 
+5. **Highly recommended**: Configure the time zone for your users in Okta. That will determine how dates/times for your users are displayed in New Relic. If you don't set a time zone, we use UTC time for those users unless they've [set their own time zone](/docs/accounts/accounts-billing/general-account-settings/default-time-zone-setting). Time zone is specified in IANA Time Zone database format, also known as the "Olson" time zone database format (for example, "America/Los_Angeles"). There are several ways in Okta to configure time zone settings, so consult the Okta docs if more detail is needed. Here's one way to do this in the **Assignments** tab: 
    * In the **Time zone** field, enter the default time zone for members of the group. 
 6. Click on **Save and go back**.
 7. Repeat the steps to add a group until all desired groups have been assigned to the application.

src/content/docs/accounts/accounts/automated-user-management/onelogin-scimsso-application-configuration.mdx

@@ -125,7 +125,7 @@ Assign the New Relic SCIM/SSO application to a user:
 4. From the OneLogin Users page, click the user you want to assign the application to.
 5. From the user's page, click **Applications**.
 6. From the user's application page, click the plus sign and select the "New Relic by Organization" application.
-7. Important: Updating users' time zones is important, as charts and other user assets display times. Default is UMT. From the **Edit New Relic by Organization login for user** page, enter the user's time zone in IANA Time Zone database format (also known as the Olson time zone database format) and click **Save**.
+7. Important: Updating users' time zones is important because [many New Relic features make use of that setting](/docs/accounts/accounts-billing/general-account-settings/default-time-zone-setting). The default format is UMT. From the **Edit New Relic by Organization login for user** page, enter the user's time zone in IANA Time Zone database format (also known as the Olson time zone database format) and click **Save**. Your users also have the ability to [set their own time zone](/docs/accounts/accounts-billing/general-account-settings/default-time-zone-setting). 
 8. If you're using **Roles** to define your New Relic capability groups, from the user's application page, click the proper role(s) for the user and then click **Save User**.
 
 ### Step 5. Set your users' user type [#user-type]

src/content/docs/accounts/accounts/automated-user-management/roles-permissions-automated-user-management.mdx

@@ -32,6 +32,3 @@ This access is given by creating three [access grants](/docs/accounts/accounts-b
 To learn more about how access grants work, see [User management concepts](/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-concepts#understand-concepts). 
 
 For tutorials on creating new groups and custom roles, see [User management tutorials](/docs/accounts/accounts-billing/new-relic-one-user-management/tutorial-add-new-user-groups-roles-new-relic-one-user-model/).
-
-
-

src/content/docs/accounts/accounts/automated-user-management/tutorial-manage-users-groups-scim.mdx

@@ -82,7 +82,7 @@ You can use the SCIM API to send a `POST` request to `/scim/v2/Users` to create
 We recommend providing the following attributes for the best user experience:
 * `name.givenName` The user's first or given name.
 * `name.familyName` The user's last or family name.
-* `timezone` The user's timezone in IANA Time Zone database format. 
+* `timezone` The user's time zone in IANA Time Zone database format. 
 
 
 ```

src/content/docs/agile-handbook/sprint-mechanics/meetings-and-ceremonies.mdx

@@ -49,7 +49,7 @@ We break our work into two-week sprints. The new sprint starts on a Tuesday with
 Each squad does their own backlog grooming and sprint planning, and manages their sprint backlog independently. We do retros together so we can talk through issues that affect both squads and share expertise and ideas.
 
 <Callout variant="tip">
-Why do we end sprints on Mondays and start Tuesdays? This funny schedule makes things easier to work across timezones. If we ended sprints on Fridays, our Barcelona-based writers would need to do retros and grooming on Friday evening, and who wants that?
+Why do we end sprints on Mondays and start Tuesdays? This funny schedule makes things easier to work across time zones. If we ended sprints on Fridays, our Barcelona-based writers would need to do retros and grooming on Friday evening, and who wants that?
 </Callout>
 
 ## Sprint planning [#sprint_planning]

src/content/docs/alerts-applied-intelligence/new-relic-alerts/advanced-alerts/advanced-techniques/outlier-detection-nrql-alert.mdx

@@ -87,11 +87,11 @@ These use cases will help you understand when to use the outlier threshold type.
 
   <Collapser
     id="timezone-related-changes"
-    title="Notify for timezone-related changes"
+    title="Notify for time zone-related changes"
   >
     The number of logged in users for a company is about the same for each of four applications, but varies significantly by each of the three time zones the company operates in.
 
-    You can set a notification for when any application starts getting more or less traffic from a certain timezone than the other applications. Sometimes the traffic from the different time zones are the same, so you would set up the alert condition to not be notified if the time zone groups overlap.
+    You can set a notification for when any application starts getting more or less traffic from a certain time zone than the other applications. Sometimes the traffic from the different time zones are the same, so you would set up the alert condition to not be notified if the time zone groups overlap.
   </Collapser>
 </CollapserGroup>
 

src/content/docs/data-apis/ingest-apis/metric-api/report-metrics-metric-api.mdx

@@ -264,7 +264,7 @@ Each metric data point map in the `metrics` array uses the following key-value s
       </td>
 
       <td>
-        **Required**. The metric's start time in [Unix time](https://currentmillis.com/). Defaults to the current time in UTC timezone. This field also support seconds, microseconds, and nanoseconds. However, the data will be converted to milliseconds for storage and query. Metrics reported with a timestamp older than 48 hours ago or newer than 24 hours from the time they are reported are dropped.
+        **Required**. The metric's start time in [Unix time](https://currentmillis.com/). The default uses UTC time zone. This field also support seconds, microseconds, and nanoseconds. However, the data will be converted to milliseconds for storage and query. Metrics reported with a timestamp older than 48 hours ago or newer than 24 hours from the time they are reported are dropped.
       </td>
     </tr>
 
@@ -387,7 +387,7 @@ The block can include:
       </td>
 
       <td>
-        The metric's start time in [Unix time](https://currentmillis.com/). This defaults to the current time in the UTC timezone. This field also supports seconds, microseconds, and nanoseconds. However, the data will be converted to milliseconds for storage and later querying.
+        The metric's start time in [Unix time](https://currentmillis.com/). This defaults to the current time in the UTC time zone. This field also supports seconds, microseconds, and nanoseconds. However, the data will be converted to milliseconds for storage and later querying.
       </td>
     </tr>
 

src/content/docs/distributed-tracing/trace-api/report-new-relic-format-traces-trace-api.mdx

@@ -178,7 +178,7 @@ The Trace API JSON payload is an array of objects, with each object representing
       </td>
 
       <td>
-        Current time in UTC timezone
+        Current time in UTC time zone
       </td>
     </tr>
 

src/content/docs/infrastructure/amazon-integrations/troubleshooting/no-data-metric-streams.mdx

@@ -49,7 +49,7 @@ Metrics are processed, mapped, and stored as received from AWS CloudWatch metric
 
 These guidelines should help understand the root cause of the discrepancy:
 * Check that the same function is used on the metrics (for example `average`, `min`, `max`).
-* On the New Relic side, make sure you filter the same timestamp or timeframe (considering the timezone) to show the exact same time as in AWS CloudWatch.
+* On the New Relic side, make sure you filter the same timestamp or timeframe (considering the time zone) to show the exact same time as in AWS CloudWatch.
 * When using timeseries, the New Relic user interface might perform some rounding based on intervals.
 
 You can get a list of the raw metric received by time using a query like this one (note that no function is applied to the selected metric):

src/content/docs/infrastructure/host-integrations/host-integrations-list/oracle-database-monitoring-integration.mdx

@@ -5857,7 +5857,7 @@ The integration captures data for the following Oracle Database configuration pa
           </td>
 
           <td>
-            Time with timezone format.
+            Time with time zone format.
           </td>
         </tr>
 
@@ -5877,7 +5877,7 @@ The integration captures data for the following Oracle Database configuration pa
           </td>
 
           <td>
-            Timestamp with timezone format.
+            Timestamp with time zone format.
           </td>
         </tr>
 

src/content/docs/query-your-data/nrql-new-relic-query-language/get-started/nrql-syntax-clauses-functions.mdx

@@ -503,7 +503,7 @@ Every NRQL query will begin with a `SELECT` statement or a `FROM` clause. All ot
 
     The **default** value is **1 hour ago**.
 
-    Use the `SINCE` clause to define the beginning of a time range for the returned data. You can specify a timezone for the query but not for the results. NRQL results are based on your system time.
+    Use the `SINCE` clause to define the beginning of a time range for the returned data. You can specify a time zone for the query but not for the results. NRQL results are based on your system time.
 
     When using NRQL, you can set a UTC timestamp or a relative time range:
     - Timestamps use the format `YYYY-MM-DD HH:MM:SS ZZZZ`. For instance, `FROM Transaction SELECT count(*) SINCE '2021-12-25 00:00:00 +0000' UNTIL '2021-12-25 23:59:59 +0000'`.
@@ -867,7 +867,7 @@ Every NRQL query will begin with a `SELECT` statement or a `FROM` clause. All ot
       ...
     ```
 
-    By default, query results are displayed in the timezone of the browser you're using.
+    By default, query results are displayed in the time zone of the browser you're using.
 
     Use the `WITH TIMEZONE` clause to select a time zone for a date or time in the query that hasn't already had a time zone specified for it.
 

src/content/docs/release-notes/agent-release-notes/net-release-notes/net-agent-6181390.mdx

@@ -10,7 +10,7 @@ version: 6.18.139.0
 
 ### Fixes
 
-* Fixed an issue that caused some transactions to report start time in the server's local timezone instead of UTC.
+* Fixed an issue that caused some transactions to report start time in the server's local time zone instead of UTC.
 * Additional bug fixes to remedy a SerializationException caused by the agent.
 
 ### Upgrading

src/content/docs/release-notes/agent-release-notes/php-release-notes/php-agent-422099.mdx

@@ -26,4 +26,4 @@ Background transactions that are Laravel Artisan commands are now named. Instead
 
 #### UTC offsets in agent logfiles
 
-The log file format has been extended to include the UTC offset of the local timezone. This makes it easier to match log entries to time windows in the New Relic UI.
+The log file format has been extended to include the UTC offset of the local time zone. This makes it easier to match log entries to time windows in the New Relic UI.