Detect timezone not only on a logon form

[sootsnoot]

Prerequisites

• I have searched for duplicate or closed issues
• I can recreate the issue with all plugins disabled

Describe the issue

Using purelymail.com webmail, which uses roundcube 1.6.8. Messages in the inbox are shown with times that appear to be GMT. I'm running Windows 10 with Chrome 131.0.6778.205. If I go to https://webbrowsertools.com/timezone/ I see
Time on Local Machine | Fri Dec 27 2024 12:03:41 GMT-0500 (Eastern Standard Time)
which is correct, while messages sent at that time show 17:03

What browser(s) are you seeing the problem on?

Chrome, Firefox

What version of PHP are you using?

No response

What version of Roundcube are you using?

1.6.8

JavaScript errors

No response

PHP errors

No response

[alecpl]

In master we removed use of jstz detector and now we're using the straight browser API. So, if that is a timezone detection issue it probably will be fixed this way. Reference: #8965.

Are you able to verify the content of the POST request sent when you log into Roundcube? It should include the detected _timezone. That would tell us whether this is in fact a timezone detection issue or something else.

[sootsnoot]

I'm using roundcube 1.6.8, hosted by purelymail.com. And according to #8965, the removal of jstz has a milestone of 1.7-beta. When I use Chrome devtools to record network interactions and login to inbox.purelymail.com, I see this POST request:

Request URL:
https://inbox.purelymail.com/?_task=login&_mbox=INBOX
Request Method:
POST
Status Code:
302 Found
Remote Address:
3.221.185.110:443
Referrer Policy:
strict-origin-when-cross-origin

With a payload of:

_task: login
_mbox: INBOX
_task: login
_action: login
_autologin: true
_user: rich@freestylefarm.org
_pass: PURELYMAILPASS|PUnxrFqECUyHnKBIC/SYeyZ1OW44EnVglfxiIX213MduxOi+0Wfg/NR5jS194Jx0mTxF8yLpvPK7hR43E6CgcQ==|6MU1WObOZ4Wue/qF2lzsoouJ2BteDItIZxjKFvAmI/f1je2ph8oCixyhbqVULL6v58ZPUvhP/g8B14Zsj0HXcA==

Where should I see the detected _timezone if this worked correctly?
BTW, I just set the timezone back to _auto_, sent another test email, and sure enough the message is displayed with GMT date,

I don't own the purelymail hosting, but is there some way I could test roundcube 1.7-beta to see if it fixes this problem?

[alecpl]

This page uses a custom (external) logon page that bypasses Roundcube logon page. So, I suspect the timezone detection is not being done at all, as normally it would be done on Roundcube logon page.

inbox.purelymail.com will have to detect the timezone and pass it to Roundcube as _timezone POST parameter. Or we'll have to consider detecting the timezone later if not specified yet.

[sootsnoot]

I have forwarded your reply (and a link to this conversation) to purelymail.com support. IMHO, as a web developer myself, having the roundcube logon page include the browser's timezone in a POST parameter seems very strange. If the code that displays the logon page can determine the timezone, then the code that processes the POST parameters could just as easily determine the timezone without relying on a POST parameter for it. Relying on a POST parameter to supply the timezone seems kinda weird/awkward/unreliable.

[alecpl]

Browsers do not sent timezone identifiers in headers or nothing like that. So, it need to be "detected" using javascript and passed to server side. Nothing strange here.

[sootsnoot]

I know that, and have implemented it myself in js. What I said was that I find it odd that roundcube chose to rely on the logon page to load the javascript to detect it, and then pass the result to the landing page in a POST parameter, given that apps are likely to replace the logon page, like purelymail does. Instead, it could have the javascript loaded by the page that the logon page lands on for successful logon, and that page could then pass a timezone POST parameter on the next click.

…

On Thu, Jan 2, 2025, 02:19 Aleksander Machniak ***@***.***> wrote: Browsers do not sent timezone identifiers in headers or nothing like that. So, it need to be "detected" using javascript and passed to server side. Nothing strange here. — Reply to this email directly, view it on GitHub <#9738 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADU7JPGEP4SVR73MVB6D2D2ITSBJAVCNFSM6AAAAABUI4BIUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRXGM3DIOJRGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[sootsnoot]

Or perhaps more conveniently, in an XHR request.

…

On Thu, Jan 2, 2025, 09:04 Rich Peterson ***@***.***> wrote: I know that, and have implemented it myself in js. What I said was that I find it odd that roundcube chose to rely on the logon page to load the javascript to detect it, and then pass the result to the landing page in a POST parameter, given that apps are likely to replace the logon page, like purelymail does. Instead, it could have the javascript loaded by the page that the logon page lands on for successful logon, and that page could then pass a timezone POST parameter on the next click. On Thu, Jan 2, 2025, 02:19 Aleksander Machniak ***@***.***> wrote: > Browsers do not sent timezone identifiers in headers or nothing like > that. So, it need to be "detected" using javascript and passed to server > side. Nothing strange here. > > — > Reply to this email directly, view it on GitHub > <#9738 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AADU7JPGEP4SVR73MVB6D2D2ITSBJAVCNFSM6AAAAABUI4BIUSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRXGM3DIOJRGU> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[ScottPeterJohnson]

It's not a problem to add this to our login page, I just didn't realize this was how it worked.