Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2008-12-20 20:25:43

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,848
Website

Re: [request] Bounty: Update MDP Calendar

FireFusion wrote:

Make one for inclusions and you’ll have the perfect plugin.

?? I don’t get it. An event is automatically included by the very fact of you having written the article! Assuming that article is in the section that you’ve told the plugin is your ‘events’ section, of course.

Why would you want to go the extra step of specifying it should be included again? Please explain.

Last edited by Bloke (2008-12-20 20:28:02)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#12 2008-12-20 21:52:34

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 3,976
Website

Re: [request] Bounty: Update MDP Calendar

just seen this and feeling faint :-) Can’t donate as much as the heavyweights but perhaps 50 of hard European currency would help.


TXP Builders – finely-crafted code, design and txp

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,848
Website

Re: [request] Bounty: Update MDP Calendar

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!


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,848
Website

Re: [request] Bounty: Update MDP Calendar

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)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,848
Website

Re: [request] Bounty: Update MDP Calendar

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:

  1. The event now only shows up on the one day (correctly) on the calendar
  2. 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…


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

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

renobird
Member
From: Gainesville, Florida
Registered: 2005-03-02
Posts: 786
Website

Re: [request] Bounty: Update MDP Calendar

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

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,848
Website

Re: [request] Bounty: Update MDP Calendar

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 :-)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,848
Website

Re: [request] Bounty: Update MDP Calendar

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)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

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

net-carver
Archived Plugin Author
Registered: 2006-03-08
Posts: 1,648

Re: [request] Bounty: Update MDP Calendar

StefBloke

Interesting PHP timestamp article.


Steve

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,848
Website

Re: [request] Bounty: Update MDP Calendar

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

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


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

Board footer

Powered by FluxBB