[eric.maziade.afsi]

Hi,

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.

[eric.maziade.afsi]

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.

[Isomorphic]

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?

[eric.maziade.afsi]

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.

[Isomorphic]

12.0 nightly-builds have been restored - please retest with a build dated August 8 or later.

[Isomorphic]

Thanks for the notification - we have someone looking at why the 12.0 nightly builds have stalled and will let you know when a new version is available

[eric.maziade.afsi]

Thanks for the detailed report - we've fixed this for builds of 12.0+, dated August 5 or later.

Hello,

As of today, when I download the latest from 12.0, I get SmartClient_v120p_2021-07-06_Pro. Will there be a new build with for August 5 or later ?

[eric.maziade.afsi]

Thank you for the fast response !

[Isomorphic]

Thanks for the detailed report - we've fixed this for builds of 12.0+, dated August 5 or later.

[eric.maziade.afsi]

Hello.

We recently went live with our time zone solution, making use of the resolutions above.

Our users ended up finding a new issue related to the "default display time zone".

We have it on our 12.0 setup (confirmed it as being an issue on 12.1 as well).

Basically, a good enough difference of time offset between the browser and display time zone can cause the months to be mislabeled in the time zone picker.

Here's a screenshot of the reproduced problem where all months in the picker are labeled as the preceding month.



Here is the HTML snippet to reproduce the issue (html explains how to setup the operating system environment to reproduce)

<p>Set your local time zone to something that is 13 hours after the target offset of -05:00; you'll need to restart the browser for it to pickup the system time zone change.</p>
<p>Ex: Brisbane (+10:00)</p>

<p>Open up the date picker and click to change the month. "January" will be labeled "December"; I expect it is due to the internal representation of the date holding a time of 12:00 which would be brought back more than 12 hours into the preceding day and month)</p>

<script type="text/javascript">// <![CDATA[

// Still messes up with a double conversion.

DateUtil.setShortDisplayFormat('yyyy-MM-dd');
DateUtil.setInputFormat('YMD');
Time.setDefaultDisplayTimezone ('-05:00');

var localOffset = new Date().getTimezoneOffset() / 60;
document.write('<p>Effective offset in hours ' + (localOffset - 5) + '</p>');

if (localOffset - 5 > -12) {
document.write('<p>Offset not good enough to illustrate the issue</p>');
}
else {
document.write('<p>Your current setup should illustrate the issue</p>');
}

var form = isc.DynamicForm.create({
numCols : 1,
width : 300,
top : 200,
fields : [{
name : 'message',
type : 'date',
editorType : 'DateItem',
useTextField : true,
title : 'Date picker'
}]
});

form.show();
// ]]>

</script>

[Isomorphic]

In fact, this one hadn't been fixed in later versions - but it has now :)

[eric.maziade.afsi]

Great! Thank you. Looking forward to it.

Regards,
--
Eric

[Isomorphic]

This had already been fixed in later versions (not recently) and we'll port the fix back to 12.0 today. Please retest with a build dated April 15 or later.

[eric.maziade.afsi]

Tried the latest update. Most of it is working, but there is an issue left wit the "today" button, which is a bit harder to reproduce.

If you take a look at `DateChooser.todayClick` in ISC_Forms, you'll see that it gets the date from a new Date() object - which causes the browser's time zone to be applied to the result.

It should most likely be using a `Date.getLogicalDateOnly(new Date())` instead, which serves to get over this hurdle.

Here's my test situation:

• DefaultDisplayTimeZone is +12:00 (to match Fiji TimeZone).
• Browser time is currently 2012-04-14 10:00 AM (EDT)
• Current time in Fiji is 2012-04-15 02:00 AM (GMT+12)
• isc.DateUtil.getAsDisplayDate(new Date()) = Wed Apr 14 2021 22:04:20 GMT-0400 (Eastern Daylight Time)
• By comparison, using Date.getLogicalDateOnly(new Date()) = Thu Apr 15 2021 12:00:00 GMT-0400 (Eastern Daylight Time)
• Clicking on "Today", will move the date back to 2012-04-14, which is yesterday in Fiji time.

Reagards,
--
Eric

[eric.maziade.afsi]

The necessary changes have been ported to 12.0 and will appear in the next build dated April 9 or later.

Note that you *do* need to setInputFormat("YMD") and install a datetime version of your custom-format, in order for parsing to work properly in both date and datetime items.

I've waited a few days, but the latest nightly is still SmartClient_v120p_2021-04-03_Pro.zip (we're April 13th).