Blog post publication date and profile time zone setting. This is on Telligent 9.2.

As this is job service related, it uses the server's time. Work was done for version 10 to more reliably standardize on UTC internally everywhere with conversions to/from user time, so this should actually work as you're expecting.

Michael Monteleone we have a scenario that we deem as a bug.  I don't believe it is addressed in 10.0.  Here is the scenario: our server is set to Hawaii time.  We have a user who's computer time is set to Hong Kong (18 hours ahead of Hawaii).  When he creates a blog post, the "Publication Date" under the "Options" tab is set to the user's current computer date/time.  When he creates the post, it does not show up in the blog post list widget.  When an admin were to look at the list of blog posts in the Control Panel, it is set to "Scheduled".  We believe that it is NOT the correct behavior because the user's intention is to create the post now.  But because he is in a timezone that is ahead of the server time, the post will not be displayed until 18 hours later.

You will need to test the scenario backwards:

Have User A (with computer timezone in Hong Kong) writes a blog post and publishes.  Nobody regardless of what timezone can view the blog post.

This was tested in 10.0.0.4689.  But you can test this in your latest version to see if this is a problem.

Out of Curiosity, what is your communities timezone set to vs what the actual web server is set to at the OS level?

Actual web server is set to Central Time Zone.  Community timezone (in Control Panel) is also set to Central Time Zone (UTC-6).

Ok thanks, I thought I had it repro'd for a moment, but even running in reverse it seems to be working so I will keep looking

This is a screenshot of me posting a blog post.  It says it will be posted tomorrow.

I have found something, it appears this was a known issue that was fixed in 10.1, which could explain alot on my side.   I will be reviewing the bug in question some more but it looked pretty close to what you described.

That could explain it.  I don't have the latest version of 10.x.  Please let me know what you find.

Another question to help with a scenario that could be the culprit.   The user who  is writing the post, is their user profile Timezone AND computer timezone the same?   And when viewing the blog create/edit post widget(screen) on the options tab is the Date for publication actually what is considered "now" based on the user profile or is it different than the actual current time?

The user profile timezone is most likely not set the same as the computer timezone.  The scenario is that we have staff who is based in Hawaii but travel to Asia.  The traveler uses a computer in which the timezone is set to Hong Kong as an example, but he/she does not bother to change his user profile timezone, because the travel is temporary.  When the user is creating the blog post, on the options tab, the Date for publication is the current date/time according to the computer time.  But from our server's perspective (Central Time Zone), that date/time is in the future, thus not publishing the blog post until several hours later.

This will create the discrepancy you see.  All visible times in the platform are based on the profile and not the browser.  I have found a discrepancy in this that we will most likely need to fix(it needs further discussion) but as a general rule, dates are converted and displayed based on the profile.  The default publish date being displayed on create however, at least in 10.1, seems to be incorrect and possibly corrected after more discussion internally.

This will create the discrepancy you see.  All visible times in the platform are based on the profile and not the browser.  I have found a discrepancy in this that we will most likely need to fix(it needs further discussion) but as a general rule, dates are converted and displayed based on the profile.  The default publish date being displayed on create however, at least in 10.1, seems to be incorrect and possibly corrected after more discussion internally.

To follow up, we were able to resolve this issue with the following work item (was affecting blog as well):

Will this hotfix be applied to any of the 9.x releases?

No.  As was stated earlier in the thread date handling in 9.2 is significantly different, therefore fixes applying to 10.1 are not applicable to 9.2.

Also to add, this bug is not really relevant to this thread, the issue you are seeing was already corrected and released in 10.1