Get rid of restrictions on future-dated posts

[alexbayleaf]

Title:
Get rid of restrictions on future-dated posts

Area:
posting

Summary:
DW doesn't allow you to post a future-dated post, and then follow it with a present-dated post. There are probably other restrictions along these lines. I suspect they are all there for historical reasons that don't matter any more, and I propose we get rid of them.

Description:
I came across this bug when crossposting from my Wordpress blog using JournalPress. My Wordpress blog (and my DW, for that matter) both have their timezones set as Australia/Melbourne, which as you probably know is almost as far in the future as it's possible to be without being a hobbit. So, I posted post A from my wordpress blog, and it was crossposted. Then I went to post another post, locked to my access list, directly on my DW. I was greeted with this error message:

<blockquote><strong>Error updating journal:</strong> Incorrect time value: You have an entry which was posted at 2012-10-01 02:02, but you're trying to post an entry before this. Please check the date and time of both entries. If the other entry is set in the future on purpose, edit that entry to use the "Don't show on Reading Pages" option. Otherwise, use the "Don't show on Reading Pages" option for this entry instead. </blockquote>

Initially I was going to submit some kind of bug report, but then I got to thinking... why is this limitation there at all? It has the whiff of something that was done for historical reasons, back in LJ's early days, and hasn't been revisited.

Why do we care about future-dated posts anyway?

Before sticky posts, people used to post future-dated posts (eg. dated 10 years in the future) so they would always show up at the top of their journal. This has been superseded by the sticky post feature, though I suspect some people may still use the old technique.

<user name="azurelunatic">, on IRC, suggested that it might also have something to do with people's computers having really wacky times set on them. I can see this being a problem a decade ago, but I think almost everyone's computer these days using <a href="http://en.wikipedia.org/wiki/Network_Time_Protocol">NTP</a> to automatically set the time, yes? So this would be a much rarer thing than it used to be.

I don't actually have a good feeling for what the solution is here, but I wanted to raise this suggestion to ask:

1) what benefit is there to limiting posting in this way?
2) do those benefits still apply, or are they historical only?
3) can we just get rid of it?
4) if not, can we modify it so that only egregious badness is prevented, but posting from a third-party client in another timezone is permitted?

For the purposes of voting, please consider the suggestion to be "get rid of future-date limitations on posts to the greatest degree possible."

Poll #11813 Get rid of restrictions on future-dated posts

Open to: Registered Users, detailed results viewable to: All, participants: 56

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
24 (42.9%)

Should be implemented with changes. (please comment)
7 (12.5%)

Shouldn't be implemented.
10 (17.9%)

(I have no opinion)
13 (23.2%)

(Other: please comment)
2 (3.6%)

Comments

[inthetatras]

I'm going to wait and see what the discussion turns out like, but I definitely want that limitation removed.

[denise]

azurelunatic was correct: the restriction was originally put into place because of the combination between how "recent entries" pages are constructed and completely wacky time offsets. A ridiculous percentage of support requests, back in the day, were from people whose computers were set to some wacky time in like 1970 or something due to power failure, BIOS reset, yadda (or just a really slow system clock): they would post, with a date of like 1/1/1970 or whatever, and because the recent entries page sorts by user-provided timestamp and not by system time (to allow for backdated posts et al) their entry would appear to be lost but would in fact have been sorted all the way back to the beginning of the epoch.

It was really, really, really common at the time (I want to say like 2003? 2004?) and it was a huge support burden, so the restriction was put in to keep people from doing it accidentally, and making it so that you had to explicitly set the "date out of order" flag if you really did want that entry all the way back there.

I'm not convinced that NTP is widespread enough to make it not be a problem; I still see people posting with really wacky dates in ways that look unintentional often enough.

[swaldman]

FWIW, as somebody who never used LJ before DW came along, I have *never* understood what that "Don't show on Reading Pages" option did or what it was for. Now it makes (a little) more sense ;-)

Suggestion for a more intuitive approach:
- On the update page, initially show a "now" timestamp from the server, taking account of the user's time zone
- If somebody wants to edit this, either let them just edit it, or they have to click a button or enable a check box to be able to do so
- If the user has edited the time, use the time that they edit it to. If they don't choose to edit it, use the server-provided time.

This would mean that the only time a user-provided date was used would be if they made a deliberate effort to provide it - so it should avoid picking up odd times from users' bad clocks. Probably? :-)

Disadvantage: Time zone shenanigans and resulting confusion. People will have them set wrongly, and people (like me) who travel and change time zone often may get annoyed.


(also, just as a data point, I used to use the far-future-date technique in place of a sticky post, because that way it mirrors to LJ correctly.)

[denise]

Time zone shenanigans are really, really hard, though. We do try a basic level of it and it's really really really hard.

[axiom_of_stripe]

time zones suck so much.

[melannen]

Would having a warning for obviously off-kilter dates, but still allowing the post, work?

And is that an issue for future dates - i.e. could you keep things as they are for past-dated things, but allow them for future dated things? Or do people occasionally show up with their computer clocks set to the future?

[denise]

Yeah, in the future is also common, and then something corrects it and all of a sudden they have problems posting regularly -- that was the tradeoff.

In conclusion, time is hard.

[azurelunatic]

I know someone who is currently consistently posting 2 years in the future because of shenanigans like this.

[arethinn]

I know someone who is consistently posting 17 years in the future because of this.

[azurelunatic]

That's impressive.

[arethinn]

She made a "so far in the future I'll probably never have to worry about it" kind of "fake sticky" post, and it seems to have corrupted all the dates somehow, won't let her post posts with the actual date but forces them all to be 2029. (I still think it could probably be fixed with some workaroundy kind of steps but she seems to prefer resigning herself to the issue.)

[denise]

Yeah, that can be very easily fixed (and the steps are actually in the error message that you get): edit the future-dated post and check the "date out of order" checkbox on it. (Then she'd have to edit the other posts to have the correct time, but still.)

or, of course, make the post sticky instead of mucking around with future-dating.

[arethinn]

or, of course, make the post sticky instead of mucking around with future-dating.

This is LJ we're talking about, so not an option (unless they've introduced that in their own new revision of their update page - I haven't looked). The original date hiccup was years ago and she's gone with it since. Manually fixing all the posts made in the meantime would be hideous.

[azurelunatic]

Simplest is to edit date after posting. Then go find the original, edit, ticky the backdate/date out of order box, and slowly go through the others and fix their dates.

[arethinn]

Yeah, I don't think that's going to be happening - we're talking years' worth of posts. She's more active on Facebook these days anyway, so it wouldn't be at all worth the effort for her, I would guess.

[azurelunatic]

I would like, and maybe this can happen with the re-envisioning of what an entry is, to be able to view one's journal (at least the past two weeks, and more for paid accounts, perhaps?) in server-time order, sort of like a reading page filter with only one member. That could be a really spiffy troubleshooting tool to help take care of any shenanigans caused by this change.

[ratcreature]

How would these posts show up on your reading page? I mean, iirc, date out of order posts don't show. I don't want to miss a whole bunch of posts just because someone posts from a different time zone.

[kerravonsen]

I'm terribly uncertain about this, because I'm afraid of things breaking, yet on the other hand, it seems reasonable.

[inalasahl]

I still future date posts. I future date posts that I want to work on now (so initially they are posted set to private), but that I want to make public at a later date. I future date them to the date I plan to publicly unlock them. I like it especially if I'm working on something with a partner, and I need to give them the post URL now, but we won't be unlocking for a couple of days. I suppose I could just change the date when I unlock, but I like to have everything ready to go and not have to remember any changes.

[kyrielle]

The new posting page, that's in beta, is ultimately planned to have (but doesn't yet) saved drafts and scheduled posting.... that should be handy once available! :)

[azurelunatic]

It doesn't look offhand to me as though any part of this suggestion would break your use case.

(Though on a separate note, under the current way things are built, entries do stop showing up on reading pages 14 days after they are initially posted, even if they're edited later, so if you find you're having trouble with people not seeing entries, that could be one possible cause.)

[melannen]

I would support removing the limitation (unless it breaks stuff), but I would want:

a) to still get a warning that you're posting something with a weird date (sometimes, say, you're posting something that's been in an open tab for, *cough*, days, and the reminder to change the timestamp is nice);

b) to still have the "don't show on reading list" option. I've never used sticky posts, but I use that regularly - because I sometimes actually use my journal as a journal rather than a blog, so I'll backdate a series of posts that were, say, written on paper while I was off-internet, or something, and I don't want them flooding the reading page. There are other reasons too - like if I have to lock an old post for some reason and want to put up a public placeholder explaining that it was locked if people come looking. It's nice to have a way to post something public without broadcasting it. It remains a very useful option.

[azurelunatic]

(As I mentioned in IRC) With this, I would want a view available that has the time the entry actually hit the server, not necessarily the main view, but some form of debug view.

It should be available to:
* The original poster (journal owner or community entry creator)
* Community admins
* People with the appropriate support priv (who exactly gets this would be a definite discussion to have)

[alexbayleaf]

OK, I've been thinking about this overnight and I have an idea of how I'd like it to work. This may or may not make sense ;)

1. On the server, posts are stored with their posting timestamps expressed in UTC.

2. On the reading page, posts are displayed in order of their posting timestamps (in UTC), but the displayed times are given in the reader's local timezone as expressed in Account Settings.

3. The Create Post page will be modified to change the date UI, and make it more like Wordpress's -- the default posting time is "Immediately", and you have to click on a something to pop out a date UI to pick another time.

3a. Assuming you leave it as "immediately", the posts timestamp will be the moment at which the "Post" button was clicked and it hit the server. This gets rid of the "oops I've had the tab open for three days" problem.

3b. If you choose a date/time explicitly, there'll also be a checkbox saying "show on reading page".

4. API changes. These are intended to be backward-compatible, and to not break functionality if the same client is used for LJ and DW. The changes are actually in the behaviour on the server end. So, when a post is made using a third-party client:

4a. if no date-time is provided by the client, post with the current time as if "Immediately" were selected.

4b. if that date-time given is within 24 hours of current time, behaviour is as if time were selected explicitly on the posting page and "show on reading page" were selected.

4c. if the date-time is further distant (1970, etc), behaviour is as if time were selected explicitly and "show on reading page" were NOT selected.

4d. if the client provides an explicit "show on reading page" flag, then that overrides the previous points.

4e. not actually an API issue, but a related point: all these settings should of course be stored and should be editable via editjournal afterwards.

5. Remove the behaviour in the Create Entry page that blocks you from posting if you have posts out of order. Replace it with a warning that mentions that you appear to have posts out of order, and links so you can edit them if desired, but don't make it compulsory.

[jeshyr]

+1 to this as my "with changes". It sounds entirely more sane than the current arrangement!

[alexwlchan]

+1 to all of this. I was about to write a long comment with my thoughts, but you seem to have written everything I wanted to say.

[swaldman]

+1. I've never quite understood why somebody's posts would appear in the future (compared to when they posted them) just because they are in a different time zone ;-)

[azurelunatic]

Point 2 makes me itchy, because the author's local time of posting is still relevant metadata in long form, even though I do without it just fine on say Twitter. I have the phrase "Nothing good happens after 2am" rattling around in my brain because of my recent tv intake, and I do take a look at the set time (more than the date) when reading.

[turlough]

I like this. +1

[cheyinka]

I definitely don't want posts to be displayed with their posting timestamps; displaying them in that order, whether reading page or recent page, is fine (assuming they're not purposefully backdated), but I'm with azurelunatic about the beneficial nature of knowing when the poster made the post.

Too, I very much don't want the default behavior to be "set the time to whenever I finish the entry".

5 on its own seems like it could work, I suppose...

[denise]

3a. Assuming you leave it as "immediately", the posts timestamp will be the moment at which the "Post" button was clicked and it hit the server. This gets rid of the "oops I've had the tab open for three days" problem.

auuuuuuugh no no no no no no

(There is a very large group of people, myself included, who want entries to post at the time you OPENED the posting tab, even if it was open for three days.)

I don't actually know if we can keep backwards compatability if we do what you specify; the posts-out-of-order thing is a protocol warning, not part of the site's frontend. I am not sure if changing it would break clients.

Also, yeah, I really don't want to know what time so-and-so wrote/posted the entry in *my* timezone, I want to know what time they wrote/posted the entry in *their* timezone. I don't think I'm the only one. That's going to require at least two additional settings. :(

[musyc]

I like a lot of this, but 3a is a NOOOOOOOOOOOO to me. I do not ever want the site to list my posting time as "when I finish the post". I want it to always, always be "when I start the post", no matter how long ago that was. *gets the BIKESHED EVEN SPLIT pompoms ready*

[montuos]

+1

If nothing else of this entire suggestion gets implemented, I would still want to see 3b. It frustrates me amazingly that a post cannot show up in reading pages only because I want it timestamped mere hours or even just minutes earlier than an existing post.