this is the one i was thinking of #14860

#14860 is unrelated to this bug.
It deals with the tip set or not to user tz.
It does not point to this important issue which is that the item should not be set to pending when using Today after clearing the field, even if the time is in my example changed to local PC time instead of UTC.

is this a change in behaviour? if so when did this change happen?

TBH, I don't know.

thats the key. if it has always been this way then i would say its not a problem. if it has not then we need to find out what made the change instead of writing new code to patch over with a bandaid

Whether it is new or not (Which would mean no one noticed it until now, rather weird...), it is a real problem and has to be solved. I will wait to see what happens with this article wrongly set to pending when the new time (2017-08-30 10:31:10) = UTC.

You are missing my point. If it is a new problem then we must look to see where and what caused this problem to appear BEFORE trying to create a fix. Who knows what other issues were created by that code. We have to stop writing code to fix things without looking to see what broke them in the first place. Thats how you end up with spaghetti code that makes no sense and creates problems in the long run.

If it has always been this way then after x years with no reports I would say it is not a problem

Can someone do tests on previous joomla versions please?

On 30 Aug 2017 11:40 am, "Brian Teeman" notifications@github.com wrote:

You are missing my point. If it is a new problem then we must look to see
where and what caused this problem to appear BEFORE trying to create a fix.
Who knows what other issues were created by that code. We have to stop
writing code to fix things without looking to see what broke them in the
first place. Thats how you end up with spaghetti code that makes no sense
and creates problems in the long run.

If it has always been this way then after x years with no reports I would
say it is not a problem

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#17770 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AALFscVx9OBx5NciTiKxFZ-n0HEVNphrks5sdS3wgaJpZM4PHDLk
.

@dgt41
I have the feeling this is due to the new calendar. Can you check?

Will test on the last 3.6.x

Same issue in 3.6.5. Can't believe this. The bug has been there for ages... The calendar always picks the local time when choosing today. It does not take into account the global config setting at all.

is it a bug then?

If I set the calendar fields to use filter="server_utc" instead of filter="user_utc"
It solves the issue here.

Yes, I think it is a bug.

filter=user_utc has been there since at least 2010

@infograf768 @brianteeman that was the reason I proposed that the calendar field should sent and receive from the front end only UTC datetime but that was a hard B/C break (?) as many people commented back then.
Anyways we should definitely do that for J4, in the mean time I don't think that this is easily patchable (by the way is server side code not js, check the data in the controller)

Just tested on a 2.5.28 and it does works fine. The time displayed corresponds to the user_utc and the item is not set as pending.

@infograf768 i think 3.x has some extra code for the user_utc compared to 2.x.
I think it's these lines:

We always read the input as UTC and convert it to server or user but the user submitted the date with their local timezone (most of the times the browser will have the timezone to the area that the user is living). There is the inconsistency...

@infograf768 this should run only when the code is coming from the db, for the data that comes from a form input we need to convert it to UTC. That will fix the problem

@dgt41
patch welcome as thsi is very ennoying.
I guess that code has been tested in winter when GB is pure UTC for local users too ?

@infograf768 unfortunately I have no clue how to distinguish if the value comes from the form or the db at that point of execution, any ideas are welcome

tested a pre-PR by @dgt41 which solves the issue here.

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/17770

closed as having Pull Request #17823

Re-opened. PR had side effects and was reverted.

2 years later and I guess either this has been fixed or no one sees it as a bug worth fixing

@brianteeman it will worth the effort if someone could implement [edit] for J4 [/edit] my suggestion in my first comment:
that was the reason I proposed that the calendar field should sent and receive from the front end only UTC datetime

As we are now in rc and code freeze I am assuming that this is not going to be addressed.

There is no point in keeping issues open if they are not accepted