Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#46 Today 18:39:51
Re: Latest version 4.9
A further thought: the Timezone Pref instructions are, I think, unclear. The way it’s worded implies it’s the user’s timezone that needs to be chosen. But (if I’m reading the code right) it should actually be the timezone of the server.
The user’s timezone (the person using the admin side to create content) and the visitors timezone (viewing the site) could be anywhere in the world and depends on what the browser tells us is their timezone.
General guidelines state that handling dates correctly, requires:
- Storing them in UTC.
- Doing calculations in UTC.
- Applying the server offset when displaying dates.
However. Things get complicated when someone’s setting an article datestamp to be an event. E.g one that starts on 30 Nov 2026 at 15:00. If they set the article to that datetime and hit Publish, the server offset will be applied. And, a secondary problem is that, by the time the event begins, DST will not be in effect, but it is in effect today (in the UK at least) when the article is published.
Burdening the user to know the server’s timezone offset when creating article dates, and taking into account whether DST will be in effect at the time the event occurs, and whether it differs from DST at the time the article is Saved, is quite an ask.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
#47 Today 19:16:15
Re: Latest version 4.9
UTC storage would be fine for our purposes if CONVERT_TZ() (or some php equivalent) worked well outside of the unix epoch, but it does not (currently) seem so. I guess it internally depends on UNIX_TIMESTAMP(), but if the latter worked well, our problem would be solved anyway (by reverting to pre-4.9 code). Actually, recent mysql/mariadb/etc servers can handle the post-2038 dates (on 64-bits systems), but not the pre-1970 ones.
What we could do in 4.9.2 is patching the dst issue for the unix epoch dates and not care about 1 hour gap for the other ones.
Offline
#48 Today 19:37:33
Re: Latest version 4.9
etc wrote #343380:
What we could do in 4.9.2 is patching the dst issue for the unix epoch dates and not care about 1 hour gap for the other ones.
This conversation is a bit over my head, so I may be misunderstanding this last sentence. It is definitely important that posting an article in the moment makes it live in the moment and not an hour later. Sorry, that’s probably stating the obvious.
TXP Builders – finely-crafted code, design and txp
Offline