[issue] Timezone creating incorrect datetime in txp:posted

placenamehere · 2006-02-12 15:59:07

(note: i searched for previous reports, but didn’t see any posts on this specific timezone issue, forgive me if this is a dupe)

I wanted to try and setup the templates on ChunkySoup.net to output in an hatom format.

To do this i needed to get the specific time of the post, including offset from GMT so I’m using the txp:posted with the appropriate strftime format:

Which outputs something like the following:

THE BUG: the timezone offset outputted is the timezone the server is in, and not the timezone the txp install is set to creating an INCORRECT date stamp.

The install is set to -0500
The local server time is -0800

The accurate time of the post was 2006-02-11T02:03:00-0500 .. . so the txp:posted tag is actually showing the wrong time in this case.

This doesn’t surface in cases where I’m not showing the timezone on the posted date… built in formats output the proper date (X hours ago, other date formats are accurate to my local timezone and the time of the post) but its just in this case where I’m explicitly formatting the date with a timezone that the formatter is failing.

Last edited by placenamehere (2006-02-12 15:59:35)

zem · 2006-02-14 00:34:43

That’s a limitation caused by PHP’s frustrating lack of timezone support. %z will not give the correct result.

placenamehere · 2006-02-14 01:34:26

I’m not sure I follow…

Textpattern is handling the storage of the timestamps as well as the timezone offsets (be they different from the server timezone or not).

(in the mean time i’m using <code><txp:posted format=”%Y-%m-%dT%T” />-0500</code> but its ugly and not at all portable)

zem · 2006-02-14 01:38:52

To support time zones without any help from PHP, we had to use an ugly hack. As a result, %z will not work.

There is no solution until PHP supports time zones properly, and everyone updates to that version.

placenamehere · 2006-02-14 01:50:31

I understand the php issue at the root of it… I just don’t see why the txp:posted tag is allowed to output an invalid date when there is enough information to output a formatted timestamp that equates to the actual time posted.

zem · 2006-02-14 02:01:39

The txp:posted tag is outputting the correct time and date, based on the information above. The time on the post is 2006-02-11T02:03:00, in the -0500 time zone. txp:posted is displaying 2006-02-11T02:03:00, which is correct.

The output of the %z token is the only incorrect thing, far as I can see. Once you’ve taken %z out, is there anything wrong with the output?

placenamehere · 2006-02-14 02:34:55

The problem with the output is that I can’t get a complete date (either with no offset @“Z” or the correct offset) out of the txp:posted tag.

In the particular case of hatom, I need to do just that. (and elswhere in textpattern, particlarly atom.php the feeds the logic is there to do the proper math and output the proper time at no offset)

The problem with hardcoding the offset as I posted above is that the solution isn’t portable. And in this particluar case I really do want this to be portable. Partly because it will be used as a proof of concept / example case for hatom implementation, and also because in the back of my mind the next templates I setup would be downloadable/distributed (perhaps as part of the template competition, but I’m not sure of that at the moment.). That also cuts back on the value of a smarter posted tag as plugin.

I know where %z is coming from when its passed blindly to strftime, but if the app that allows shifting off local server time for the time stamps it stores tell me why not solving this case isn’t a textpattern bug.

(while i’m looking at the code.. why is the time being stored in local server time and not GMT? wouldn’t working off GMT prevent issues involving site migration or dev servers and live servers being in different local times?)

Last edited by placenamehere (2006-02-14 02:56:35)

zem · 2006-02-14 05:43:29

if the app that allows shifting off local server time for the time stamps it stores tell me why not solving this case isn’t a textpattern bug.

The question isn’t whether or not it’s a bug (I’d call it a limitation, since it’s not intended to work), but whether or not fixing it is feasible. Like I said: sure thing, as soon as everyone’s running PHP 5.1 or 5.2 or whenever TZ support works properly.

Seems to me a more sensible solution for what you’re trying to achieve is a tag that outputs the time in GMT.

Either way: prove me wrong, send a patch.

(while i’m looking at the code.. why is the time being stored in local server time and not GMT? wouldn’t working off GMT prevent issues involving site migration or dev servers and live servers being in different local times?)

The local time thing is a legacy from old code.

Last edited by zem (2006-02-14 05:44:12)

placenamehere · 2006-02-15 15:37:57

> zem wrote:

The question isn’t whether or not it’s a bug (I’d call it a limitation, since it’s not intended to work), but whether or not fixing it is feasible. Like I said: sure thing, as soon as everyone’s running PHP 5.1 or 5.2 or whenever TZ support works properly.

Seems to me a more sensible solution for what you’re trying to achieve is a tag that outputs the time in GMT.

</blockquote>

What I’m going to end up doing for this particular scenario is just that.

<code><abbr class=“published” title=”<txp:php>global $thisarticle; echo gmdate(‘Y-m-d\TH:i:s\Z’,$thisarticle[‘posted’]);</txp:php>”><txp:posted /></abbr></code>

gives me what I need… and while I do think that txp:posted should be smart enough to undo any “smart” date logic you’re doing a short term direct solution could be an additional argument for txp:posted thats just a flag on wheter to request gmt date or not… <code><txp:posted gmtdate=“1” /></code> or something of that nature.

Either way: prove me wrong, send a patch.

Way to convince me its worth sending you a patch and that it really would be welcomed.

Mary · 2006-02-15 17:12:29

placenamehere,

Concerning patches, you (and anyone) is free to make any kind of patch to Textpattern. If you pop over to the dev mailing list (via the link above), you can join that list and send it in (if it’s large, then a link to where it can be download), with an explanation as to what it is for, the rationale, etc. The list is open to anyone and that way specific solutions can be analyzed and discussed by the core and contributing developers, including yourself.

Part of the problem is the existing legacy code and the fact that we don’t want to prevent people from upgrading from older versions of Textpattern. If you take a look at how a couple certain functions work, you’ll see the problem:

posted, /textpattern/publish.php, starting on line 697 (latest svn revision)
safe_strftime, /textpattern/lib/misc.php, starting on line 900
tz_offset, /textpattern/lib/misc.php, starting on line 887

placenamehere · 2006-02-18 00:49:58

I agree to an extent on the source of the problem mary.

At a certain point you usually have to draw the line, bite the bullet and just do what’s right™. in the case of storing as GMT rather then local time it may require an update script that does some massaging of exiting dates or something similar to get past the big roadblocks.

as for patches, i understand that anyone can contriubte.. i’m on the dev list, etc and have been around here for some time.. its a matter of me getting the time to decide what I think is the right angle for a solution (kill offest flag, extra format /speecific gmt request flag / looking for%z/%Z and replacing them with the proper values before stftime gets the format string) and then actually getting someone to discuss it.

my last attempt to ask what approach would be more acceptable for a patch went without a single response.

goes back to looking at what the hell the file date logic is doing

Mary · 2006-02-18 03:55:58

What’s “right” doesn’t include arbitrarily dropping support for everyone else’s sites. Easy to say and do, but not “right” or fair. All changes must be accompanied with an upgrade mechanism. Period. Agree or don’t agree, that’s a universal mark of quality software. That doesn’t mean it can’t be discussed, simply that the whole picture must be looked at, not just a particular problem personally being faced.

As for lack of response on “acceptable approach”, I wouldn’t know happened or did not happen there. Sorry that left you feeling out in the cold.

Textpattern CMS

Textpattern CMS support forum

#1 2006-02-12 15:59:07

[issue] Timezone creating incorrect datetime in txp:posted

#2 2006-02-14 00:34:43

Re: [issue] Timezone creating incorrect datetime in txp:posted

#3 2006-02-14 01:34:26

Re: [issue] Timezone creating incorrect datetime in txp:posted

#4 2006-02-14 01:38:52

Re: [issue] Timezone creating incorrect datetime in txp:posted

#5 2006-02-14 01:50:31

Re: [issue] Timezone creating incorrect datetime in txp:posted

#6 2006-02-14 02:01:39

Re: [issue] Timezone creating incorrect datetime in txp:posted

#7 2006-02-14 02:34:55

Re: [issue] Timezone creating incorrect datetime in txp:posted

#8 2006-02-14 05:43:29

Re: [issue] Timezone creating incorrect datetime in txp:posted

#9 2006-02-15 15:37:57

Re: [issue] Timezone creating incorrect datetime in txp:posted

#10 2006-02-15 17:12:29

Re: [issue] Timezone creating incorrect datetime in txp:posted

#11 2006-02-18 00:49:58

Re: [issue] Timezone creating incorrect datetime in txp:posted

#12 2006-02-18 03:55:58

Re: [issue] Timezone creating incorrect datetime in txp:posted

Board footer