[Barry]

Hi Chip! Just checking in one more time – if you need further support please shout back, otherwise I’ll close this in a day or two (you can of course still open a new thread if you’re unable to reply before then).

[Barry]

Hi Zeke: I’ll close this thread now.

[Barry]

Yep, that may be sensible. What I’m going to do is close this thread. If on the release of 3.0 the same problem does persist (it shouldn’t!) do feel free to create a new thread.

[Barry]

Great!

[Barry]

Hi Bernhard. I suspect this is a bit of an oversight and I don’t currently think there are any methods of resolving this other than a custom script or working through it manually – but I appreciate that would be quite a pain, so bear with me while I have a chat to another team member.

[Barry]

Hi Len, I’m not currently seeing this behaviour – the event at the top of http://thedepanneur.ca/events/past/ is dated Jan 13 and on http://thedepanneur.ca/events/upcoming/ a different event dated Jan 15 is showing first.

I’d like events to ‘expire’, i.e. move from upcoming events to past events, when they hit their end time… is this possible?

So they should do that, but there may be factors (such as if you are using a caching plugin) that impact here. Can you let me know if it is still a problem and we can go from there?

Thanks!

[Barry]

Nice! Thanks for getting in touch Phil, I’ll close this thread now but if there are any further issues just post away in a new thread.

(Hopefully it’s plain sailing from here on in, though!)

[Barry]

Are you comfortable with CSS? Could you add a rule like this either to the bottom of your custom events.css (if you have a custom version) or else to the bottom of your theme’s stylesheet?

div.widget.eventsAdvancedListWidget ul.upcoming li div {
padding-left: 16px;
}

[Barry]

Excellent, thanks for posting back Ann 🙂

[Barry]

Michelle: does Bethany’s comment help/did you find the cause and do you need any further support here?

[Barry]

Thanks Bethany: yep that is another cause for this error we’ve been seeing a little more of recently – thanks very much for highlighting that one.

[Barry]

Hi Phil – could you provide a specific URL where I can see this? I did take a look using the URL you provided when you opened this thread but couldn’t identify the problem.

[Barry]

Thanks first of all for confirming that a larger range of -/+ hours works with FBEventsTimeCorrection works – I’ll update that blog post to reflect this.

Just need to figure out why two events registered in FB with same time and city would give me different offsets.

So I do understand that you don’t control them and didn’t set the original events up on Facebook, but I suppose that’s sort of my point. Something I’ve seen in North America-related posts is one person/account having times that default to Pacific, and others that have been set explicitly to work on Mountain time or whatever.

And – could be mistaken here but I believe this *used* to be the case – for a while all event date/times defaulted to Pacific, as a sort of universal Facebook time, which caused some amount of confusion. So it’s not beyond the realms of possibility that a user setting or quirk of Facebook is behind the discrepancy.

[Barry]

Hi Tiago:

Bear with me here because timezone issues are always require a little mind-bending, so if I go off-beam just let me know.

My question is how can two facebook event’s that are set to same time in the same city be imported with different offsets?

It’s possible to set a timezone on FB for events so, if this is different for each event, then that might explain the discrepancy. I’m genuinely struggling to think of any other reason.

Do you guys practice daylight saving time or anything like that and are these events from two different FB accounts? Even if they belong to the same account it’s still possible that they were added using different timezones.

2) the offset is bigger than 12hs so BEventsTimeCorrection() does not like it

True, I’ll put my hands up and admit I didn’t quite anticipate this sort of extreme. Though I haven’t tested this (perhaps you have already?) you could possibly amend this line (in FBEventsTimeCorrection):

if ($this->hours < 0 or $this->hours > 12) return false;

To:

if ($this->hours < 0 or $this->hours > 24) return false;

And see what you can get away with. Again, I haven’t tested that out at all so it may not work as expected.

[Barry]

OK – well the best way to modify something like the date/time format is at template level, rather than altering the custom field data directly.

First thing to do is read up on theming and template overrides in particular, so that any changes you make are done safely and in an update-resistant manner.

What you are probably going to want here is to edit your custom list.php and find this line of code:

echo tribe_get_start_date();

And try changing it to:

echo tribe_get_start_date(null, false);

And that should stop the time from also being displayed.

[Author]

Posts