Assets for JSM: Setting Date Attributes is misrepresented in Issue History since it is aware of Timezones and alters the presented information based on them. This makes the value appear incorrect.

XMLWordPrintable

    • 7
    • Minor
    • 7

      Issue Summary

      When setting Date Attributes, Assets stores the Timestamp at Midnight GMT.
      This breaks presentation of the Date in the Object History, since that converts the Timestamp to the User's timezone, which then misrepresents the value.

      Steps to Reproduce

      1. Create an Object with a Date Attribute the User can set.
      2. Set the Date Attribute to a Value.
      3. Change the Date Attribute's Value.
      4. Make sure your Timezone is negative relative to GMT, such as GMT-5, GMT-6, GMT-7, etc.
      5. Review the Issue History to see that it shows the Date as the day before you set it to in step #2 & step #3

      Expected Results

      The Date change information should be presented correctly in the Object History.
      i.e. it shouldn't change based on User Timezone. It should always show exactly the date the User set it to.
      It shouldn't be aware of Timezones.

      Actual Results

      It is aware of Timezones for Date Attributes, which causes this mismatch to occur, misrepresenting the data in the Issue History when viewed via the User Interface.

      Workaround

      There is no currently known workaround, except to use a DateTime attribute instead to be able to set the Time, and thereby, avoid this issue.

      Cause

      When the DateTime is recorded in the Database, it is not being translated to the actual Timezone the User was in when selecting the value.
      Meaning, whenever someone in GMT-5 selects 2024-10-30 as the Date Value, it's recorded in the Database as 2024-10-30 00:00:00, which is assumed to be in GMT since all DateTime values in the Database are in GMT.

      Whenever this is presented in the Object Activity, the User's Timezone is applied. So that 2024-10-30 00:00:00 would be converted to 2024-10-29 19:00:00, making it look incorrect in the Object Activity.
      In other words, the problem is that the Timezone isn't being applied when the Value is initially recorded for the Attribute. If that happened, the Object Activity would always look correct to the User who made the change.

      In step form to illustrate this, what is currently happening:

      1. User in GMT-5 picks 2024-10-30 as the value for the Date attribute -> It is recorded in the Database as 2024-10-30 00:00:00. No conversion happens from GMT-5 to GMT. The Value is just recorded directly. Effectively, it's recorded as GMT-5.
      2. User goes to view Object Activity -> The 2024-10-30 00:00:00 is pulled and rendered in the UI, but it is converted from GMT to GMT-5 since the UI is aware of them, so it is now 2024-10-29 19:00:00. The Value is being treated as GMT despite not being converted to that from GMT-5 in Step 1.

      What should be happening instead:

      1. User in GMT-5 picks 2024-10-30 as the value for the Date attribute -> It is recorded in the Database as 2024-10-30 05:00:00, having been converted from GMT-5 to GMT.
      2. User goes to view Object Activity -> The 2024-10-30 05:00:00 is pulled and rendered in the UI, but it is converted from GMT to GMT-5 so it is now 2024-10-30 00:00:00, appearing correctly.

      This would create a new issue, where this isn't communicated to the End User and they'd be confused why different Users see different Values, but that's a simple information issue.
      A tooltip, or other modal could communicate this by showing the Timezone being used when interacting with Date Attributes to emphasize that they are used & considered.

      The current behavior is unexpected, since it is not converting the value correctly when storing it, and the Date Picker in the UI is also aware of User Timezones.

            Assignee:
            Mursil Sayed
            Reporter:
            Payden Pringle (Inactive)
            Votes:
            9 Vote for this issue
            Watchers:
            17 Start watching this issue

              Created:
              Updated:
              Resolved: