query.cc: $date returns time in GMT only

[Sage]

The $date function uses gmtime() instead localtime() for converting time into tm structure. It is not possible to get time according locale system settings.

[Olly Betts]

localtime() isn't really the correct answer either - the timezone the server is in is usually an "implementation detail". On an intranet it will probably work OK (unless your intranet spans multiple timezones), but not for a website on the internet.

But there certainly is an issue here - UTC is an arbitrary choice.

Ideally we'd determine the timezone of the end-user automatically and use that, but it's not trivial to find - it requires some javascript magic, and a mechanism to get the information back to the server.

Perhaps in the short term, localtime() is better than gmtime() since at least it works better for most intranet cases.

[Olly Betts]

Further research reveals that you can't actually get the user's timezone from javascript. You can get the current offset from UTC, but that doesn't tell you how much offset to apply for arbitrary dates - it could easily be 2 hours wrong (e.g. UK DST to NZ non-DST vs UK non-DST to NZ DST).

The best option seems to be to write out javascript code to output the time_t values as a formatted date, like the patch I'll attach shortly. This doesn't seem ideal though - it's kind of klunky, and changing the date formatting is very fiddly and error prone.

I don't think we need to hold up 1.1.0 for this, so moving the milestone setting. If we come up with a clean fix (or decide the attached patch is actually OK) it can go in for 1.1.0 of course.

[Olly Betts]

Patch to use javascript to format dates in the user's timezone

[Sage]

Thank you very much!

I think that in most cases decision is to add new function (like $localtime) or maybe optional parameter (local/global time). This way we can see in most APIs for generation user output.

In global systems users get default timezone (for example - local server time zome) and can change it during registration or in profile settings or left unchanged. Timze autodetection is not primary solution and by the way in some cases javascript is not supported.

[Olly Betts]

But adding $localtime (or a parameter) doesn't really fix anything - it would just use a different wrong-for-many-users timezone.

Requiring users to configure their timezone is rather unfriendly and would require implementing a whole new user configuration UI. That's a lot of work for what feels like a poor solution to me.

I realise javascript may not be supported or may be disabled. If it isn't, the patch I attached falls back to reporting in UTC (by using <noscript> tags).

[Olly Betts]

Triaging milestone:1.1.1 bugs.

[Olly Betts]

I'd rather not do this mid 1.2.x.

[Olly Betts]

Committed a reworked version of the patch in r13147.

Documented that $date works in UTC in r13148.

We could add a way to convert a time_t using a specified timezone, but it's not clear to me how this should work.

Just adding a new $localtime function (or equivalently a boolean "localtime" flag to $date doesn't seem flexible enough, as it just gives a choice of "localtime" or "gmtime", and often the right answer isn't either of those.

If we add a timezone parameter, what format should it be? Text name (in which case what formats are understood)? Hours offset (which could be a fraction as there are 30 and even 15 minute offsets)? Minutes offset?

So while the JavaScript fix may not be to everyone's taste, I'm going to close this ticket as I believe it does address the issue. If someone wants to come up with a sensible patch to offer an alternative approach, feel free to do so.