Scheduled Posts - Timezone problem with datetimepicker

[AndyHee]

• [X ] I have searched open and closed issues for duplicates

Bug Description

The new feature for scheduling posts defaults to a time in the past.

In my case the proposed time is set to almost 7 hours in the past! This confused me as I assumed the time shown in the schedule was UTC, which didn't turn out to be the case.

Steps to Reproduce

1. Set server's system time to UTC
2. Set time in Friendica's user setting to UTC+07
3. Open New Post composer
4. Click on "Scheduled at"

Expected Result:

Scheduling time/ date defaults to the future.

Screenshots

Platform Info

Friendica Version: 2021.08-rc

[MrPetovan]

Timezones strike again!

[annando]

Weird thing is: It is working here.

[AndyHee]

Just to clarify. Everything works well when posting! I set the scheduled time for the post and it goes out correctly, according to my local time. Great!!

What doesn't work is the time initially offered in the drop down time. It shows the server's actual system time. In my case that is 7 hours behind my local time.

Example:

It's 10.05 AM here (ICT Time Zone). I open the composer and see this:

It shows 3.05 AM which is UTC, which is my server's system time.

I then set this to 4.00 AM assuming that the post will go out in 55 minutes. But it doesn't it, it goes out immediately. If I set it to 11 AM, it does goes out 55 minutes in line with my timezone.

Conclusions:

• Timezones work for scheduling!

• The drop-down menu time display doesn't understand timezones

[annando]

Do you have these problems as well when creating events? Can you check this?

[AndyHee]

Nope. In events the drop down menu gives out local time.

[MrPetovan]

Progress report: Minimal.

Looking into the code I was able to find out that the user-set timezone in your settings has absolutely no impact on the date and time picker itself. The server timezone may have had an impact on the maximum date/time that can be selected from the picker (set at now + 6 months according to the server timezone), but the main driver for showing the default date in the picker is your computer/browser timezone that Javascript can query.

On the other hand, the timezone you set in your user setting is crucial for the correct date/time to be set when submitting the form because we received the scheduled date/time as a formatted string which we assume is formatted according to the user's provided timezone.

I'm going to try to change my computer timezone, see if I can make a difference, but I'd like you to check it is correctly set to the same as your user setting in Friendica as both need to be the same for both the display and the saving to work seamlessly.

[MrPetovan]

Update: I changed my computer timezone to UTC +07:00, and after a reload of the Compose page the default date/time in the picker correctly changed to what my computer clock is saying, which is Wednesday September 15th at 5:07 AM (it is Tuesday September 14th 6:07 PM on the American East Coast).

So I would double-check your computer-set timezone as it is what drives the display of the default value in the picker.

[annando]

I guess we can move this to the next milestone? It seems as if this isn't a problem in the core, but a local problem, since no one else seem to be able to reproduce it?

[MrPetovan]

Yes, let's remove it from the milestone until we get more details from @AndyHee

[AndyHee]

Thank you @MrPetovan for looking into this and sorry for the delay; I had overlooked your ping.

I think you're correct that this relates to the browser. As soon as you mentioned this, I immediately recalled that my main browser has tighter security/ privacy measures. My Firefox browser is set to give out UTC regardless of my local/ system time. This a none default setting that has been recommend by some to prevent an analysis of how your IP relates to your timezone for instance.

I double checked with a different browser and everything works as expected.

Now this raises the issue how shall we proceed. The current design (taking the browser time) is convenient in case users move across different timezone and find themself on a different PC with the local time. Although I understand the posting time at the moment is taken from elsewhere.

However. the move away from browser time is in line with a more fundamental concern of reducing identifiable information. In this view browsers should not give out a time value full-stop or at least not by default.

I personally would plead for a move away from browser time. Either way, I think what would be useful would be a display near the time picker what timezone this actually is.

[MrPetovan]

Thank you for the follow-up, I agree we should use the user-set timezone information since we have it anyway, and I don't like this issue being about a discrepancy between the user-set timezone and the browser timezone because it shouldn't be depending on the browser timezone at all.

Now the problem is that the Javascript time picker we use doesn't have a timezone option and can only display the time according to the browser timezone at the moment.

[AndyHee]

Thanks for explaining this so well; I now understand the intricacy here of using JS libraries.

Yes, the discrepancy between the user-set timezone and the browser timezone is a problem. It would lead to confusion in the following cases:

• Users travel across timezones and the updated browser timezone makes them belief they are setting the scheduled post according to their new timezone
• The browser clock is spoofed by default (e.g tor browser) or user intervention.

So a timezoneOffset option in the datetimepicker would defiently be a great improvement.

For practical purposes, I also think that a display of the current user-set timezone near the date/ time field would go a long way. This would give absolute certainty when the post will go out.

I'd envisage something like this; it could even have a hyperlink to the user setting for swift adjustment for timezone travellers:

If you could give me an indication whether this is realistic to implement in terms of work effort and avoiding bloat, I would open a separate feature request.

[MrPetovan]

The timezone display and the link to the settings are both fairly easy to implement.

[AndyHee]

Great. New feature request here: #10737