Aggregated home page doesn't respect time zones on future posts

[GoogleCodeExporter]

What steps will reproduce the problem?
1. I am in central time, the server is in eastern time.  So 11AM happens on the 
server before it happens to me.
2. Enter a post with a future posting time, say 11AM.  This is entered into 
subtext_content with a time of 11AM.
3. At 11AM this post appears on the aggregated home page.  At 11AM it isn't on 
the individual blog page yet.  The admin screen also shows it as a future post 
and one that isn't posted yet.

What is the expected output? What do you see instead?

I would expect posts to appear on the aggregated home page at the same time 
they appear on the individual blogs.

What version of the product are you using? On what operating system?

I'm on 2.5.1.0 on Windows Server 2003 running SQL Server 2005.

Please provide any additional information below.

I poked around in DNW_GetRecentPosts and what I believe calls it.  It only 
passes in a single date to compare against.  I believe subtext_content is 
storing dates in my timezone rather than the server time zone.  That would mean 
the aggregated home page is basically ignoring the time zone.  The further away 
you are from the server the worse it is.  Please note you will only see this 
issue if you are running an aggregated home page.

My guess is that this will also affect the aggregated RSS feed.

Original issue reported on code.google.com by billgraz...@gmail.com on 21 May 2011 at 3:10

[GoogleCodeExporter]

Thanks Bill. I'm looking this. Can you attach the contents of 
DNW_GetRecentPosts here? There should be a condition in that stored proc that 
looks like: 

    AND DateSyndicated <= @CurrentDateTime

Which is the same clause used by the non-aggregate homepage

Original comment by haac...@gmail.com on 21 May 2011 at 9:54

[GoogleCodeExporter]

Also, can you attach a screenshot of the "Location Settings" section of the 
admin/Configure.aspx page in your admin section?

Original comment by haac...@gmail.com on 21 May 2011 at 9:57

[GoogleCodeExporter]

Please see the attached document.  I did find 

    AND DateSyndicated <= @CurrentDateTime

in numerous places in the code.  The challenge is that for an individual blog 
it sets @CurrentDateTime correctly based on the time zone of the blog.  But on 
the aggregated home page it just used the system time to compare to all entries 
across blogs in different time zones.

I don't know if it's better to store everything in UTC (my suggestion) or have 
BOTH the aggregated home page AND the aggregated RSS adjust for time zones.

Original comment by billgraz...@gmail.com on 22 May 2011 at 1:27

Attachments:

• [The Life of a Future Post.pdf](https://storage.googleapis.com/google-code-attachments/subtext/issue-300/comment-3/The Life of a Future Post.pdf)

[GoogleCodeExporter]

Look at http://code.google.com/p/subtext/issues/detail?id=291 for more details.

Original comment by haac...@gmail.com on 22 May 2011 at 10:01

[GoogleCodeExporter]

Issue 291 has been merged into this issue.

Original comment by haac...@gmail.com on 22 May 2011 at 10:01

[GoogleCodeExporter]

@Bill, I worry about storing everything in UTC at this point because we'd have 
to convert all existing data to UTC. I believe we store it using *your* 
timezone (not the system's). So if the aggregate page is using the System 
timezone, then I need to find that code and correct it.

Original comment by haac...@gmail.com on 22 May 2011 at 10:11

[GoogleCodeExporter]

Ok, I figured out the problem and it's a tricky one. When we get the blog posts 
to display, we pass in the date and time according to *the blog* (as in the one 
you configured). We then grab all posts that were published on or before that 
date.

But in the case of the Aggregate blog, there is no configured date time. So it 
defaults to the server's timezone. What this means is I can't pass in a single 
date to the query. I'd have to pass in one per blog.

So it looks like storing everything in UTC would help us solve this problem, 
but doing so creates its own big problem, which is converting all the existing 
data to UTC. :(

But I think this is the right change, but it's quite a bit of work.

Original comment by haac...@gmail.com on 22 May 2011 at 10:27

• Added labels: Milestone-Release2.6, Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Fixed in r4213

Original comment by haac...@gmail.com on 2 Jun 2011 at 3:36

• Changed state: Fixed