Events page shows past events

I think this would take me up to half a day to fix.

Is the desired fix to get rid of those dates entirely or to move them under "Today"?

I don't think we can easily change the timezone we're using to display the date. That's set at the field level (currently set to the event's timezone), so it applies the same in lists and the event page itself. There's also anonymous users viewing this display, so if we did make it display relative to the user's timezone, the dates would change when you logged in.

Looking at the view and the code, I'm not clear on why we're seeing those dates at all, since both appear to be filtering based on the server's definition of "Today" (same Y-m-d value). I see an easy fix (change == to <=) that would move them up under "Today," but I'm not sure where to even start with any other fix.

I started the creation of a dev site named events for this. Will be done within 20 minutes.

I'm asking for shell access now and will look at this on Sunday/Monday if nobody beats me to it.

I've got a small problem here...

Technically, those are not past events, but "Today's events" in their timezone....
So I end up with Nov10 being today in Japan but I also have Nov10 in Tomorrow (if the event is in Chicago).

What do you guys think?

Note : I have changed the "dev" site to calculate the date_create('now') with the event's timezone. So at least now it shows under today instead of "Later this week".

Not perfect logic wise, but no more weird titles.

OK, I promised to look at this almost two months ago, but real life came and distracted me. Anyway, attached is a patch that fixes the oscillating header issue, between today and tomorrow for example, (with the problem explained in the patch).

ADDED: Oh I forgot to comment on the original post:

couple of events with event date - yesterday.

The reason for this strange behavior is that the event date is displayed in the local timezone. That makes kind of sense. If I look at events in New York, I would like to see the date/time in New York, not UTC. What makes this strange of course is that we sort things based on UTC. Anyway, I think this can be improved by adding "(local time)" after the event date to explain it.

The titles appear to be correct now, but the dates are still confusing. I see:

Nov 14, 2012
Nov 15, 2012
Nov 14, 2012
Nov 15, 2012

I imagine this is because the events' timezones are varying, so Nov 15 in one timezone can actually be before Nov 14 in another, but understanding that doesn't change my initial reaction of confusion. Explaining why the interface is initially confusing by adding more timezone labels seems kludgy to me. It distracts my attention from the activity of the events to timezone math, which is not really what we want users thinking about when they look at this list.

I think we should maybe take a step back and re-think this interface with less emphasis on the specific dates now that we know we can't move those dates into a common timezone as people would expect.

Explaining why the interface is initially confusing by adding more timezone labels seems kludgy to me. It distracts my attention from the activity of the events to timezone math,

You misunderstood - the extra label should be just "(local time)", not the actual timezone. We should indeed not bother the users with timezone math ... Maybe "(local time in LOCATION)" is better?

We could of course just list all entries with date in UTC which would make the list looking nice. However, that isn't very helpful either. Imagine a guy living in New York (again). He looks at the list of events and sees a lot of events taking place the 15th of November. However, those events actually takes place the 14th of November in New York. (This is the case for any event starting 7 PM or later in New York.)

I'm not sure there is a perfect solution...

It's really just thinking about timezones at all that I find distracting, not specifically math. I'm imagining the list would look something like this:

Nov 14, 2012 (local time)
Nov 15, 2012 (local time)
Nov 14, 2012 (local time)
Nov 15, 2012 (local time)

When seeing this, my thought process would be "Why is that out of order? Oh, it's local time, so those must be in different locations. That makes sense." What I want to be thinking is more like "I'm not interested in that event... Oh, that's an interesting event, I should click through to get more details, like the time."

If displaying everything in UTC is an option (I didn't think it was), I think that would be better than the date display being out of order and everything being timezone specific. Almost everything on Drupal.org (e.g. the comment times in this thread) and across the web is already displayed in a non-local time for the viewer, so while it isn't ideal, I don't think it would be confusing. By the time I post this comment, for example, it's going to say Nov 16, but it's still Nov 15 for me. That doesn't confuse me, because the times are consistently offset from my local time. It's the inconsistency that I find confusing.

I agree standard UTC isn't perfect, but I think it is better.

Actually when editing your Drupal.org profile, you can choose your timezone in Locale settings and all comments etc. will be displayed in your local time.

Oh wow, I can't believe I missed that all this time. Thanks!

+1 for grouping by month for now and improving this in D7.

[...] managed to get one event with the title "Later this week" on top of "Today

I was able to reproduce this issue. I was also able to "fix" it - see attached patched. The problem is coming from Views - past events can appear dependent on the user's time zone. (The "Later this week" event is really a past event.)

Example: This event does appear in the events list if I use "Pacific/Tahiti". If I switch to "UTC", the event disappears from the list.

If we display only months, we will still have this problem with past events and on the first day of a month we might get events displaying in the month before. Because of this I'm -1 for grouping by month.

However, since the dates are being displayed not in the user's timezone, it is really confusing.

Yes, it is, but is it really less confusing when stuff is listed per month? The (potential) one day off is the real problem. When people see the entries listed per month and think the dates are correct, they are being fooled. With the current setup, they at least understand something fishy is going on :-)

I don't understand why the view isn't displaying the dates in the user's timezone. Everything else is... I'm guessing this is a bug in the Date module's Views integration. I'll have a look.

OK, the problem with date display was in the theme - see patch 24-2 below. Now the list of events are displayed in the user's timezone. I have also removed the finished/pasted events from the list - see patch 24-3 below (which contains the fix from patch 21).

The only remaining problem is to decide if we want the local timezone, the user's timezone or both on the actual event page.

I agree that having both makes sense. Maybe someone else will add the extra date display on the event page? I guess it has to be done in the theme again.

I could do it, but I'm not a themer so I'm slow ...

Yes, the patches in #24 was the only thing I changed.

I committed the theme patch to bluecheese and merged to groups.drupal.org's repository.

This is deployed now. The current event list is especially short (2 events) on the first page, because the pager isn't accounting for the "yesterday" events we're now removing. I hadn't noticed that in testing. I think it's okay to leave as-is until we move to D7.