Confirmed.

Set Timezone on "Chicago", Published Time is (7h earlier) 2017-05-13 01:41. After change Article to Category using com_fields Published Time is 2017-05-12 20:41.

I think this has been addressed in 3.7.1 with the fix the JDate, perhaps someone can confirm that this has been fixed.

Hello folks,
any comment on this?
Having this issue in 3.7.2 :(

I am experiencing the exact same issue, in Joomla 3.7.2

confirmed ... why does changing category with fields changes the article published and created date!?!?!
this is not related to the JDate issue in 3.7.0

This is probably some JS behaviour that is doing this

The reload is caused by categoryHasChanged js function that is submitng the article form to com_fields and, with it, sending all the article form data.

Com_fields receives the article form data and redirect the app back to the article edit view (which now loads the wrong date).

@dgt41 any idea why the article form load event from user state uses the wrong date in this scenario (different timezone)? Could it be something related to the calendar?

This is probably some JS behaviour that is doing this

I think is the way the data is passed to the form the second time (2 transformations === wrong time)
Javascript should always parse and print (send to PHP) UTC dates new Date("2017-03-25T12:00:00-06:30"); but that was out of question for J3.x due to B/C break, maybe in J4?

@mbabker @wilsonge can we change the value of form field calendar to 2017-03-25T12:00:00-06:30?

i think the second time the date is 2017-03-25 12:00:00 format

Let's ping @laoneo here, he's more familiar with the Fields code

I will have a look together with @Bakual. Not an easy one to fix to keep everything intact. Basically the validate function does need to be called. From a first glance I have no clue how.

Yep, that's indeed not an easy fix. Running the validate method (which would apply the tz difference back) would require that we know the form (the XML) itself, but we don't know that at this point. Also it would mean that it fails when the form is invalid (eg no title yet). So it's not a viable solution imho.

Basically the current solution to reload the whole form with new custom fields is sort of a hack.

Ideally we would use some AJAX which replaces the custom fields (and fieldsets) itself with the new ones directly without reloading the whole form. But that is probably not that easy as well due to the possibility of template overrides. But I'd say it is the most promising approach (my JS skills lack me here however)

If we had an "autosave" feature which saves the current work into an "autosave version" in the version history, then that one could be used for the reloading. But while that would be an interesting feature, it needs someone to write it first and it's probably not simpler 😄

What about saving the original value (from DB) in State, Session or LocalStorage..
Overwrite this if the user changes the field .. maybe ? If not, we apply TZ to the "original" value

To decide if the TZ has to be applied or not (and which one, server or user TZ), you need the form definition. That one as well as the original value isn't available in the browser. So you can't do anything here. Maybe we could make it available to the browser somehow, but in the end it would just be another hack specific to fields and calendar formfields.
On server side, we already have the validate method which does change the value back based on TZ settings and form definition. So if we have to deal with it on the server, we already have the method to do it. What we don't have within com_fields at this point is the form definition.

A way would be to go over the controller of the extension (eg. ContentControllerArticle) to store the data into the session instead of the com_fields controller, just with another task like reload for example.

Please test #16665 which should fix the issue.

Closed as we have a PR for testing