I'm hoping there is just some setting I'm missing, as this seems like a serious bug, but I'm not seeing others mentioning it, so perhaps there is an easy solve.

I'm finding that the timezone for the site is based on whatever timezone was set for the most recent user updated.

Example 1)
Say it's 12pm in LA and 3pm in NYC.
I have two users. The one I've assigned to New York that I'm testing in Chrome.
The one I've assigned to Los Angeles, I'm testing in Firefox. (I also tested this yesterday with someone who was actually in a different timezone, which is how we discovered it).
My sites Regional Setting is set to UTC (although I also tested with making it NYC).

What happens is, when I update my Chrome/NYC user and clear the sites cache, this Chrome/NYC can now schedule posts for any time after 3pm. That seems fine.
BUT, if I go to my FF/LA user and try to schedule something after 12pm, I get "Error message The 'publish on' date must be in the future.", so I have to add three hours to get it to save and use NYC as my base.

Now, if I simply update my FF/LA user and clear the cache, now the opposite occurs. My FF/LA user can schedule a post for any time after 12, but my Chrome/NYC user can now schedule things up to three hours in their past. They are not both tied to LA time.

The whole time the sites Regional Setting is still UTC.

Example 2)
I update my FF/LA user and clear the site cache.
I can now schedule a post for 12:01.
I go into Chrome, update my NY user and clear the site cache.
I go back to FF, look at the record my FF/LA user just set, and it now says 3:01 pm.
This FF/LA user can’t update this record again to 12:01pm. This site now thinks it’s NY time for the LA user.

So it seems like updating a users individual timezone effects the timezone of all users site.

My concern is that an editor will update their account and all of a sudden, the timezone by which other editors schedule will have changed.

Is this a known issue? Is there a solve for this (aside from disabling users ability to set their own timezones and making them base all schedules upon a site setting)?

Thank you.

CommentFileSizeAuthor
#8 3085947-8.timezone-cached.patch1.08 KBjonathan1055
#5 scheduler-timezone-cached-from-prev-user-3085947-05.patch997 bytespartdigital

Comments

kid_baco created an issue. See original summary.

jonathan1055’s picture

jonathan1055 commented

Hi kid_baco,

That is a strange set of observations, and no I've not heard of this before and no one else has reported it. I don't think it can be caused by anyrthing in Scheduler, as from your steps and description Scheduler is only reacting to the state of your site.

Maybe it is worth you repeating the steps but at key places check what you see at /admin/reports/status for the 'Scheduler time check' section. That will show the current state of all the time settings.

Secondly, do you have the means to create a clen fresh drupal8 site and enable only Scheduler then repeat the process. It may be another module is interferring with the site timezone setting.

Jonathan

kid_baco’s picture

kid_baco commented

Hi Jonathan,

Thanks for your reply. Given how popular this module is and that you haven't heard this before makes me think it's something solvable on my end.

That said, I have added the scheduler module to a different drupal install (not completely clean, but pretty bare) and done the same kind of testing, to find the same results.

  • I create two user accounts, one with the local time NY, one with LA
  • I sign in a chrome browser with my NY user
  • I sign in a firefox browser with my LA user
  • I update my FF/LA user and clear the site cache
  • Even though I am on the east coast and it's 11am here, I'm able to go to into my FF/LA user and schedule a job to publish at 8:01am, which makes sense as it's 8am in LA
  • That said, when I go to my Chrome/NY user and add a new record, I can schedule that for 8:01 am as well, which should be impossible as that should return the "date must be in the future" error message
  • After I save that 8:01 am Chrome/NY record and go back to view it, I still see 8:01 am in the Scheduling Options -> Published On field, but looking above, I see "Last Saved: 10/08/2019 - 11:00", which is the correct NYC time for this user (the FF/LA user says "Last Saved: 10/08/2019 - 08:00", which is correct for that user.
  • When I run lightweight cron at 11:01 am est, both jobs publish.

Also, when I go to /admin/reports/scheduler in FF(LA), I see
Server time: 8th October 2019, 15:16:15 +00:00
Local time: 8th October 2019, 08:16:15 -07:00 PDT America/Los_Angeles (currently in daylight saving mode).

And if I go to Chrome, I see
Server time: 8th October 2019, 15:16:40 +00:00
Local time: 8th October 2019, 11:16:40 -04:00 EDT America/New_York (currently in daylight saving mode).

Does anything in these results setoff a red flag for you?
I'm rather baffled and hoping there is just some small step or setting I'm missing.

partdigital’s picture

partdigital commented

I want to chime in and say that I'm also reporting seeing a similar issue. I was able to reproduce it on a clean install of Drupal the only contrib module installed is Scheduler 8.x-1.1.

It saves the timestamp based on a user's timezone during the last cache clear. The problem therein lies when multiple users from different Timezones are scheduling content.

Chicago user creates a node to be published Oct 31, 2019 at 9:00 AM
- Saves timestamp 1572530400

UTC user creates a node to be published Oct 31, 2019 at 9:00 AM
- Saves timestamp 1572530400 (uses the Chicago Timezone)
- Cache is cleared

Chicago user creates a node to be published Oct 31, 2019 at 9:00 AM
- Saves timestamp 1572512400 (uses the UTC Timezone)

So scheduling form inherits the timezone of whatever user is viewing the node edit form after a cache clear.

partdigital’s picture

partdigital commented
Related issues: +#3087606: Datetime::getInfo() caches user's timezone causing unpredictable timestamps.
StatusFileSize
new scheduler-timezone-cached-from-prev-user-3085947-05.patch997 bytes

I spent some more time digging into this and it looks like it may be a Drupal Core issue. It reproduces the same behavior for the "Authored On" field.

I’ve opened a Core ticket: https://www.drupal.org/project/drupal/issues/3087606

Because this is a Drupal core issue it should be addressed there, however, I understand we can’t always wait for a core update so I’ve created a small patch which addresses the issue for this context.

jonathan1055’s picture

jonathan1055 commented
Status: Active » Needs review

Thank you @partdigital that is really helpful. I really thought it could not be caused by Scheduler. Also I wonder if core behaviour has changed recently, as this problem should have been discovered before if it has been in Core for a while. I'll follow #3087606: Datetime::getInfo() caches user's timezone causing unpredictable timestamps. and see how it goes. Good that we have a patch here for anyone who is experienceing this problem.

@kid_baco can you try the patch in #5 and let us know how you get on.

Thanks

jonathan1055’s picture

jonathan1055 commented

All the test failures are due to deprecation messages

drupal_get_user_timezone() is deprecated in drupal:8.8.0. It will be removed from drupal:9.0.0.
Use date_default_timezone_get() instead. See https://www.drupal.org/node/3009387

https://www.drupal.org/node/3009387 is the change record. It may be that we have to check the core version in code and use either drupal_get_user_timezone() or date_default_timezone_get(). We need Scheduler tests to pass at 8.6, 8.7 and 8.8

jonathan1055’s picture

jonathan1055 commented
Title: Timezone based on user most recently updated. » Entered date is stored using cached timezone from previous user
Category: Bug report » Support request
Related issues: +#2799987: Datetime and Datelist element's timezone handling is fragile, buggy and wrongly documented
StatusFileSize
new 3085947-8.timezone-cached.patch1.08 KB

The commit to core which causes this problem was on 20 Nov 2018 so it exists right from the start of 8.7.0. I have sucessfully re-created the problem, in both core 8.7 and 8.8. My steps are slightly different so I have listed them here:

  1. Clear cache
  2. Chicago user creates node 1, scheduled for 31 Oct 9:00am. On saving, the message says "will be published 9:00am", the saved timestamp is 1572530400 which is correct. (this is 14:00 in UTC, because Chicago is 5 hours behind UTC)
  3. Clear cache
  4. With UTC user, viewing existing Chicago node 1 shown as scheduled for 14:00 as expected. Create node2 , schedule for 31 Oct at 14:00. Message says "will be published 14:00". Timestamp is the same, 1572530400. Both nodes shown as scheduled for 14:00
  5. Without clearing cache, go back to Chicago user. View Scheduled Content shows both scheduled for 9am as expected. Create node 3, scheduled for 9.00am. On saving, message says "will be published 4am". Not what the user intended. Timestamp is 1572512400 which is 9am UTC, 4am Chicago time.

As you correctly deduced, the timezone has been taken from UTC user because cache was not cleared. Consequently the scheduled time is 5 hours earlier than the user wanted.

Here is a patch using the built-in date_default_timezone_get() which fixes the problem locally on 8.7 and 8.8. This patch should pass on 8.7 and 8.8 as this function is not deprecated.

jonathan1055’s picture

jonathan1055 commented
Status: Needs review » Postponed (maintainer needs more info)

Good news - #3087606: Datetime::getInfo() caches user's timezone causing unpredictable timestamps. has been fixed and committed to core 8.9 and 8.8, but unfortunately it has not been backported to 8.7.

If anyone following this thread needs it, let me know if patch #8 fixes your core 8.7 site and then I could commit this, with a @todo to remove it when core 8.8 become the lowest version we support.

jonathan1055’s picture

jonathan1055 commented
Status: Postponed (maintainer needs more info) » Fixed

Thank you kid_baco and partdigital for your help here.
It's gone two weeks without any response, so closing this as fixed. If anyone needs the correction for core 8.7 and cannot apply the patch in #8 then please re-open this issue and we can discuss a solution.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.