Added a get_timestring to Post.rb so we can get a valid datetime string for a <time> element

[gunnarhafdal]

I wanted to add a <time> element on my blog posts so I made a new method in Post.rb. Since it has to output the right timezone as well I had to change the get_datetime_object method so it returned the time in the correct timezone. Time.parse() defaults to UTC so if I made a blog post at 5 pm in Europe then get_datetime_object would return a time set to 5 pm UTC. What I did is just add the offset between my timezone and UTC back onto the time being returned.

I also added the <time> element to the sample blog template because I think it's smart to have the correct time on every post. Might make it easier for things like Hazmat to order posts in the correct chronological order.

[sts10]

Finally have some time to look these pull requests over. This is the first one I'm really looking at in-depth. I'm a bit confused though.

Is that idea here to use UTC when creating new post file names, then have the publishing mechanism convert those UTC times from the post file names to the user's local time?

If so, when Radiation creates a new post it will need to do current_time = Time.new rather than current_time = Time.new.in_timezone($my_timezone) in the create method of post.rb.

The problem here is that this will throw off the timestamps for all current users' posts. Their post file names are in their local times (say, New York time). If we change Radiation timestamp reader assume they are in UTC and subtract an offset, they will now be all off.

Let me know if I'm understanding this right.

[sts10]

So I merged your other two pull requests, giving users draft support and the ability to update a post's timestamps from the main menu. v 0.3.7 incorporates both of those improvements. Awesome work! I only made some minimal changes-- removed some unnecessary semi-colons (yay Ruby!), and added a check for if the user has a blank post.

I'm going to hold off on this timezone change for now though, as I still have the same question I had 5 hours ago when I wrote the comment above.

Thanks again for these pull requests!

[gunnarhafdal]

Thanks, glad to be of help :)

About the timezone part. The reason I'm doing it like this is because the server runs on UTC but we want to create files with our time in the filename, e.g. 2014-12-03T13+58+56-test-of-time.mdown. That hasn't changed and still behaves like it should.

What I wanted to do was to use the <time> element on my blog and show the same timestring as in the filename but with the timezone as well, e.g. 2014-12-03T13:58:56+0100.

That does not happen because when you parse the filename it doesn't see anything about the timezone and defaults to the timezone the computer runs on (which is UTC on the server). So we end up with 2014-12-03T13:58:56+0000.

Adding .in_timezone($my_timezone) is not enough because it corrects the timezone but also changes the timestamp to $my_timezone. That means that I would get 2014-12-03T14:58:56+0100 (14:58 instead of 13:58). To fix that I find the offset from $my_timezone to UTC and remove the difference, and end up with 2014-12-03T13:58:56+0100 or in the case of America/New_York I would get 2014-12-03T13:58:56-0500.

So the filenames are the same as before but we get correct timezone information to use in our HTML which is good for parsers and RSS readers and we end up with a post entry that looks like this.

<div class="blog_post" id="2014-12-03T13+58+56-test-of-time">   
  <div class="date">
    <a href="#2014-12-03T13+58+56-test-of-time">
      <time datetime="2014-12-03T13:58:56+0100"> 1:58pm, Wednesday, Dec 03, 2014</time>
    </a>
  </div>
  <div class="post_content">
    <h2 id="this-is-a-test-of-time">This is a test of time.</h2>
  </div>
</div>

I hope this clears this up. I think the git commits are pretty weird because I thought I had fixed this but when I ran it on the server everything broke. The reason being that the server was on UTC and my laptop was on Copenhagen time so everything looked fine on it.