[request] Bounty: Update MDP Calendar

Bloke · 2008-12-20 21:57:08

Much obliged, thank you very much.

Do you have any ideas for where this might go? Like, things it should do that I don’t appear to have covered in the above teaser? Have I missed anything that would make your event-based life more dreamy?

I’m having fun with tags right now and putting all sorts of crazy things in each cell to see if I can break it. Wheeeeee!

Bloke · 2008-12-21 15:10:13

This is getting silly, I should stop soon.

Updated my above teaser post with the new features I shoehorned in this morning. The holidays thing is useful as you can specify which type of events are allowed to occur on holidays. For example, you might be organising a week-long christmas party (!) so in that instance you’d want the spanned event to show up on Christmas Day (by default it would be cancelled and — depending on your plugin attributes — would either be missing from that day in the calendar or could be told to be parsed by your form so you can take action and render it differently using the calendar’s conditional tag).

I’ll have a go at documenting it this afternoon and release a copy to the kind sponsors after that. When they’ve had their fill and have given it the green light I’ll release it publicly.

Last edited by Bloke (2008-12-21 21:08:28)

Bloke · 2008-12-22 12:33:57

Well this is totally doing my head in. Trying to write a consistent calendar in TXP hurts because of the way times appear to shift when DST is applied.

I know this has been debated to death before but if I post an article called “Party!” and schedule it for August 1st 2009 at 19:00, to end at 23:59:59 (for argument’s sake: if it’s a good party, time will of course have no meaning :-p ) then when I view the calendar it pops up on the right day and shows me the event times. I’m in England (GMT) and my DST is ‘no’ in prefs.

I assume (though have no way of knowing) that if Dale thought this was a worthwhile party and saw it on my web site it would state that the time the party commences is 19:00 GMT. I don’t care if he’s viewing the site from Delaware, Billabong or Munich, the event takes place at 19:00 GMT and nothing should change that.

Michael, however, doesn’t see the site until June. He likes to party and wants to come along. I’ve changed my DST setting to ‘yes’ because some bureaucrats decided it would be a great idea to annoy me twice a year. He looks at the calendar and sees two parties — one on the 1st and one on the 2nd August — because I’ve used safe_strftime() to work out which day(s) an event starts/ends.

I’m using the <txp:posted /> and <txp:expires /> tags to show the event times to web visitors. They show up OK in the calendar, but the fact that safe_strftime() computes the offset using DST makes it look — internally — like the party starts at 20:00 and ends at 00:59:59; an hour later. Thus my calendar ‘breaks’ and thinks it spans two days.

Further, say the administrator of the site looks at the article in the admin side. It also computes the time based on DST and shows the event starts at 20:00. If he ‘corrects’ it and resave the article so the dates look ok on the article tab, two things happen:

The event now only shows up on the one day (correctly) on the calendar
The event’s start and end times are now shown incorrectly on the calendar as Start=18:00 and End=22:59:59 because <txp:posted /> and <txp:expires /> haven’t taken this into account

The upshot is, once an article is set as an event I can quite easily only show it publicly as starting at the ‘correct’ time by using the <txp:posted /> and <txp:expires / tags. Also, if I don’t use safe_strftime() and instead use PHP’s strftime() I can — internally — calculate the ‘correct’ days that the event starts and ends because the PHP function doesn’t munge the dates and take DST into account.

My question is: is it “safe” to do this and not use the safe_strftime() call? Am I going to get into a pickle later on when timezones and different character sets come into play? Can I safely not use sfae_strftime() to calculate dates? Or should I be passing other options to it (other than the user-specified gmt and lang) to calculate such times correctly?

Sub-questions / points:

What is the “best practice” here? Which functions should I use to compute dates in the plugin? The TXP ones or the PHP ones?
I don’t want to change dates and stuff for events that are ‘absolute’ in terms of where they start and end in a particular time zone
I also don’t want to go and change all my calendar and posted/expires tags to set gmt="1" whenever I change the DST pref
I’d also like the dates to show correctly in the article tab so anyone doesn’t get spooked and try to ‘correct’ an event that is actually already perfectly fine and is just being displayed inconsistently on the admin side depending on the DST/timezone in play
Is there some kind of system I can mention in the plugin docs that offers some compromise so dates always show up as intended (i.e. “always set DST ‘off’ and never use it if you intend to use this plugin; fake it using the time zone if necessary”. Or “always use gmt=‘1’ on any posted/expires tags you use”, etc)
The water murkies if the server has a different time zone to the site, or the person who posts the event is in a different time zone, or the whole site is moved to another server, but they’re probably extraneous circumstances or ones (in the frist 2 casess) that a user should be able to work around when posting details on some event that is to occur in another country. Errr, maybe?
Probably something else I’ve not thought of

Any help appreciated, I’m slowly spiralling into my own head and I don’t like what I’m finding in there…

renobird · 2008-12-22 13:54:55

Well here it is the 22nd and it sure feels like x-mas!

To quote Jakob “just seen this and feeling faint”.

I’ll throw some cash at this for sure – not quite sure what I can afford at the moment – but I’m in.

—
T

Bloke · 2008-12-22 15:23:44

renobird wrote:

I’ll throw some cash at this for sure – not quite sure what I can afford at the moment – but I’m in.

Many thanks, Tom. When I’ve ironed out a few more of the wrinkles (most of which are in my post above yours…) I’ll send you a pre-release copy to mess with. Hopefully in time for Christmas proper :-)

Bloke · 2008-12-22 17:09:24

An update while I’m in monologue mode.

In my — thus far limited — testing, it seems if I force safe_strftime() to use gmt="1" by default, then the plugin behaves itself ‘internally’ and calculates the correct offsets and things, exactly like the PHP strftime() does. While that is a relief and alleviates complex timezone calculations on my behalf, it smells ever so slightly of old varnish and I can’t help thinking I’m missing something (probably the fact I’m actually in a GMT time zone and it’ll collapse elsewhere in the world)
Nevertheless, if I do that, it also appears the plugin — internally and publicly — is immune to changes in the DST prefs setting, which is tip top in my book
If I alter the time zone in prefs, the plugin still continues to behave internally but of course the <txp:posted /> and <txp:expires /> tags render the offset times. The ‘fix’ for older events is to specify gmt="1" in your posted/expiry tags. This isn’t much of a hassle (I don’t think) because you don’t tend to change time zone very often, if at all
Conversely if you enter a new article while under the influence of a time zone, any new events using posted/expires tags with gmt=“1” will render the incorrect time, but if they are set to gmt="0" the desired time (as set in the article) is displayed. Dilemma
Of course, either way the TXP articles on the admin side “change time” as stuff is adjusted, which is a pain. The key thing to remember, I guess, is that if you see a time in an ‘event’ article that’s already posted leave it the heck alone no matter how tempting it is to correct it. And if you do have to re-save the article, make sure you take the current time zone and method in which you display times to visitors into account or it’ll fall apart upon saving

All this hair-pulling leads to a conclusion: The only way an event/calendar system can possibly work in TXP today (4.0.7) is if the administrators and people entering articles are completely consistent and the time zone/DST never changes and no articles are ever edited and resaved under a new time zone/DST. Vary any of those conditions and it gets messy very quickly. Unfortunately, I don’t think that is a reasonable assertion because a web site will evolve over time and should be able to cope with such fluctuations.

I can go someway with this plugin because I intend to enhance the conditional tag to be able to detect and react to timestamps. Thus if you changed timezone today (for whatever reason: server move, maybe), you could run a test as you rendered your calendar to see if the date was > a particular date and output posted tags with gmt=“0” from that date forward. Else use gmt=“1”. It’s not ideal but it helps; the onus is still on the site owner to understand all this time lark, and frankly it’s Einstein territory at best, but when things don’t go to plan at least there’s an avenue to wander down with some lights on.

Thus I’m with saccade on this issue: each timestamp should be stored as an epoch in the database that’s immutable and absolute (well, until 2038, but that’s another problem entirely!). Its ‘context’ — the conditions at the time of posting — should be recorded as ancilliary information in another column or two. For specialist apps like calendars it’s up to us site admins and plugin authors to use the extra columns to fit our intended use models and factor any adjustments into the design so timestamps can appear to remain constant where they need to — both client and admin side.

Going forward, if that means adding a couple of optional args to safe_strftime() and the posted/expires tags, or some better prefs in the database to allow adjustments to be made automatically, I don’t know and I’m not qualified to make those decisions. I’m rapidly approaching the opinion that there is no ‘best fit’ solution but there could probably be some kind of automatic ‘best guess’ solution that works logically for most people and can be overridden should the need arise. This will take some brain power and I don’t have the capacity, cap’n ;-)

If anyone has anything else on this I’d love to thrash it out to something workable.

P.S. the plugin still of course works, it’s just a pain in the admin side when things like DST kick in.

EDIT: aww crap, if you save an article with DST on it applies DST to the timestamp it stores in the DB so when it switches back it shows up an hour earlier, and the setting of gmt has no effect either way until you resave the article in ‘winter’. Can anyone spell m i n e f i e l BOOM…?

Last edited by Bloke (2008-12-22 20:26:32)

net-carver · 2008-12-23 13:49:40

StefBloke

Interesting PHP timestamp article.

Bloke · 2008-12-23 14:13:42

Ahaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa! There may be some light at the end of the time tunnel.

Right, that’s my afternoon taken care of. Thanks Steve :-)

net-carver · 2008-12-23 14:31:48

StefBloke

NP, hehehe. BTW, the link to php.net at the end of the article I quoted is wrong. Should go here (at least for UK clicks.)

Bloke · 2008-12-30 14:11:14

Update on smd_calendar: I’ve not got much further with DST, but the timezone thing I think I’ve cracked by simply not using safe_strftime(). I’m using PHP’s native strftime() instead which seems to stop TXP calculating the timezone offset twice and getting in a pickle. It’s holding up ok with all timezone tests I’ve run so far, and mrdale has concurred it’s working across the pond in GMT-8 land. Fingers crossed…

The plugin is up to v0.3 as of this morning but it’s not published because I’ve not finished the latest round of “can it just do…” from mrdale, which I’m trying to roll into 0.3 as well. Anyone who has an older copy and wants to try it out, get in touch because some of the v0.2x releases were brain damaged in the date department and may cause head scratching.

I’ve managed to squeeze in a cellform attribute, among other stuff, so you have the option to pretty much design your own cells on the calendar from scratch; thus if you don’t like the way the date number is displayed, you can do it yo’self.

If I can crack mrdale’s latest request it’ll be even more useful, but it’s pretty involved and is too early to say whether it’ll work the way I want it to. I was hoping to get it ready before New Year but it’s touch and go right now. Perhaps with an Easterly wind and a sprinkling of fairy dust. Sorry to keep promising it’ll be released and then not releasing it, but kind benefactors get first stab at this one.

Even if I do say so myself, this plugin is a major step forward for event management that would not be possible were it not for the brilliant stuff behind the scenes in the 4.0.7+ codebase. All hail TXP, for it is mighty.

mrdale · 2008-12-30 16:17:37

BTW: I should say that Stef’s Calendar wildly exceeds my expectations. It’s awesome. Stef always delivers far more elegance, function and flexibility that one initially asks for.

The “can it just do” that Stef mentions turns this plugin into a full-fledged events package. It’s outside the original scope (and I’ll end up sponsoring this further to the tune of a beloved ancestral cabbage)…

so I would encourage anyone who can swing it to donate something and sponsor this really useful piece of work.

Last edited by mrdale (2008-12-30 16:18:34)

joebaich · 2008-12-30 16:51:18

Bloke wrote:

EDIT: USD?! Might as well offer magic beans ;-)

Stef go for the USDs spurning any offers of beans. Though the USD is ailing, the GBP (Gordy Broon’s Pund) is ailing even more. Several months ago you would have received around 50 pence for each dollar, today you will receive around 68 pence.

I’ll add some GBP in due course.

Last edited by joebaich (2008-12-30 16:53:08)

Textpattern CMS

Textpattern CMS support forum

#13 2008-12-20 21:57:08

Re: [request] Bounty: Update MDP Calendar

#14 2008-12-21 15:10:13

Re: [request] Bounty: Update MDP Calendar

#15 2008-12-22 12:33:57

Re: [request] Bounty: Update MDP Calendar

#16 2008-12-22 13:54:55

Re: [request] Bounty: Update MDP Calendar

#17 2008-12-22 15:23:44

Re: [request] Bounty: Update MDP Calendar

#18 2008-12-22 17:09:24

Re: [request] Bounty: Update MDP Calendar

#19 2008-12-23 13:49:40

Re: [request] Bounty: Update MDP Calendar

#20 2008-12-23 14:13:42

Re: [request] Bounty: Update MDP Calendar

#21 2008-12-23 14:31:48

Re: [request] Bounty: Update MDP Calendar

#22 2008-12-30 14:11:14

Re: [request] Bounty: Update MDP Calendar

#23 2008-12-30 16:17:37

Re: [request] Bounty: Update MDP Calendar

#24 2008-12-30 16:51:18

Re: [request] Bounty: Update MDP Calendar

Board footer