Bug when using start date of date range component?

[Rupur]

Hi guys,

I am trying something out and noticed this weird effect. I have date range component and I have selected the dates you see here:

Now what I want to do is, I want to transfer those values onto another date range component but each date should be 1 year earlier and at the start and end of the month. I am using these simple scripts:

{{ moment(dateRange3.value.start).subtract(1, 'years').startOf('month') }}

{{ moment(dateRange3.value.end).subtract(1, 'years').endOf('month') }}

The strange thing is, this works just fine for the end date but not for the start date, this is the result:

Now I have tried the same scripts for two individual date components, there it works how it should:

Any explanation?

[dcartlidge]

That is weird, I assumed it was some leap year confusion but I can't seem to replicate the problem:

Can you share the component details, maybe there's some other event handlers acting on it?

[Rupur]

The components are all in their default state, I have just placed them to test this.

This is the date range component with the original dates:

This is the date component with the correct start date:

This is the date component with the correct end date:

And this is the date range component with the same functions as the previous date components but a different start value being displayed:

[dcartlidge]

Looks identical to what I tried and couldn't replicate.

If you create another daterange component and use that as the source, does the same thing occur?
ie does this happen for every daterange component you build or just this one instance?

here's my demo app for your
forum (1).json (10.5 KB)
comparison:

[Rupur]

Ok weird, I have just uploaded your file and I get a different result:

[dcartlidge]

I think it's timezones - you're GMT+0100 and I'm not.
The Moment documentation says:
moment().startOf('month'); // set to the first of this month, 12:00 am
I'm wondering if the timezone shift then takes 1 hour away from 01-02-2023 resulting in 31-01-2023

what does the start date show if you change the value to:

moment(dateRange1.value.start).utc().subtract(1, 'years').startOf('month')

[Rupur]

Ah, then it works!

But why, I don't understand what is happening? And how can I get it back to GMT+0100 ?

And how come it works with the regular date component?

[dcartlidge]

I think with any date manipulation there are things to consider such as the timezone of the data, the timezone of the viewer, the timezone of the server performing and actions etc

I've not looked into why the behaviour is different between the components - possibly one has a time stamp and one doesn't - but what you will need to do now is check what timezone you're trying to compare and modify.
Is the date entry local to the user or is it what is stored in a database etc. Converting everything to UTC time is usually the best option and then when you're displaying it or asking for data to be entered you do the conversion into local time.

[Rupur]

Sorry I have to bring this up again, it actually doesn't work if the initial date is the first, so it substracts one day regardless.

I think this is some weird issue with the date range component. I have stopped using it and instead I am using two date components.

[dcartlidge]

I think you're right, it's a bug with the start date that is changing the timezone

same issue here:

Incorrect timezone with "Minimum Date" on DateTime selector validator

That actually doesn't work, the issue is that Min Date stubbornly converts the time to the local timezone for Min Date. [image] But that got me on the right track. Figured it out with this code: {{ moment(calendarDataEntryDTStart.value).tz(calendarDataEntryAllDay.value == true ? 'UTC' : selectedUser.data.timezone || 'local').toISOString(true) }} You read in with moment, set the timezone, then use toISOString(true) to keep the offset.

If you add the "bug" tag to this post it should get listed as an issue

[victoria]

Thank you @Rupur and @dcartlidge for working on this! Created a bug report for this internally and will keep this thread updated.

[victoria]

Thanks to your feedback here, we were able to identify the bug and fix it! The fix will be coming with our next Cloud release (which is usually sometime midweek)