No announcement yet.
  • Filter
  • Time
Clear All
new posts

    Thank you.

    That fixed the month picker, but it broke the "today" picker.

    My local machine is setup at Taipei time (+08:00), we are Monday August 9th at 10h13 PM.

    As in the previous setup, default display time zone on SmartClient is at -05:00 (meaning August 9th at 10h14 AM)

    When I click on "today", I would expect August 9th, however, since the fix, I'm getting August 10th.

    Click image for larger version

Name:	Screenshot 2021-08-09.png
Views:	19
Size:	23.8 KB
ID:	266099


      The previous fix is unrelated to this second report - there have been other changes fairly recently, but we're not seeing this problem in testing against the latest 12.0.

      With local OS timezone set to Taipei, so local time 22:40, August 9, and SmartClient displayTimezone of -05:00, we see August 9 get selected when we click Today, using your previous sample code. Are you perhaps testing with different code this time?


        Thank you again for the rapid response.

        You're quite right - I fired the message too rapidly - I had different results on the clean testbed... My apologies for this.

        Here's what I found digging a bit more.

        We have initialization code that can be executed before Time.setDefaultDisplayTimezone is called (more on that later).

        This is *not* an issue with our production release (using "v12.0p_2021-04-15/Pro Deployment").

        It is with "v12.0p_2021-07-06/Pro Deployment" (most likely comes before).

        Our initialization routines are doing some date calculation ahead of time - that is before the time zone settings are asynchronously received.

        As such, we make calls to `Date.getLogicalDateOnly`, which causes SmartClient to inizalize an internal variable `Date._timezoneOffsetDate`.

        When `Time.setDefaultDisplayTimezone` is later set, it keeps using the internal `Date._timezoneOffsetDate` value with the previous offset.

        It might be worth considering clearing the internal value when defaultDisplayTimeZone is changed, as it could conceivably be a per-user setting.

        I still have to evaluation the implications of changing our initialization sequence to make sure the default display time zone is set first. I need to be sure we would not miss anything.

        Ideally, display settings would not impact the data and they could be set independently.



          The "Today" button works fine.

          I had my wires crossed with another test, it would seem. Apologies for the inconvenience and thank you again for the prompt fix on the calendar issue.