dw_dev | Can anyone make me a strong argument for keeping "you are posting in the past" checks on updating?

Can anyone make me a strong argument for keeping "you are posting in the past" checks on updating?

It's storytime with mama rahaeli: I think we've got a legacy 'feature' that can be removed, but I'm not 100% sure. Read the background and try to convince me one way or the other.

The situation as it is now: If you try to post to your journal with a time before your most recent entry, you are prevented from doing so.

(The check is in cgi-bin/LJ/Protocol.pm, lines 1323-1327; the error is "You have an entry which was posted at $u->{'newesteventtime'}, 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.")

This check was added in the LJ days (I'm not sure when, because the web gateway to LJ's source is down right now and I can't look up the history, but it was very early in my tenure so I want to say 2002 or so) to prevent a very common problem with people's computer clocks being set wrong. It was a horrible support burden (leading to dozens if not more support requests per day): someone's computer battery would be dying and their clock was set wrong because of it, or their clock would just be set a year or two off. Because entries in personal journals are displayed on the Recent Entries page by the time they're dated, not by the time the server received the post, a post dated 1970-01-01 would disappear completely: the person would post it, it would display on Recent Entries behind every other post they'd ever made, and they wouldn't be able to find it when they loaded their journal to see it so they would assume it hadn't been posted at all.

(This is not a problem in communities: to avoid the problem with having posters from many timezones, communities show all entries ordered by server time, not by user-supplied time.)

The fix definitely helped that problem, but it introduced the opposite problem (someone who posts once with an accidental date of 2038-01-01 then has to do some farting around with the backdating flag) and the whole concept of backdating in general is very hard to explain to people. It also, for us, causes issues with emailed-in posts: when someone emails a post to the site, it's posted with the timestamp in UTC (aka, DW server time), which then causes problems if someone wants to post within the 'window' of their timezone offset. (This is what made me start this post: I emailed in today's stupid kitten pic, which got a timestamp of 2014-04-21 0500 UTC, then I tried to post a second entry at 2014-04-21 0421 EDT and got the error. I've opened an issue for applying timezone offsets to emailed-in posts, but there's still the wider question to address.)

My gut instinct is that this check may have been necessary in 2002 (or whenever) when very few people had self-correcting clocks, but now it's 2014 and I don't think there's a single operating system out there that doesn't ship with the "update from timeservers" checkbox checked. I think the few people who will have disabled that auto-time-correction will be used to things behaving weirdly for them if their clock is hella off, and any potential support burden will be alleviated by the lack of having to support questions like "I posted an entry in 2020 to future-date it and now I can't update without errors".

So, discuss:

1) Do people think we can safely remove the "are you trying to post in the past" check?

2a) If not, should we switch to using system time for the "are you trying to post in the past" check? (IE, go by "time the entry was received by DW" rather than "time the user specifies for their post".)

2b) If yes, which of the two options should we take:

2b1) Eliminate all future-date/past-date checks when updating, but otherwise leave things as-is, so that entries on a personal journal's Recent Entries page are still displayed in the order they're dated, not the order they were posted;

2b2) Eliminate all future-date/past-date checks when updating, and switch to treating personal journals like communities, in which entries are displayed in strict order they're posted regardless of date specified by the user.

(I can make up some examples if people are confused about the distinction.)

I think we should get rid of the check, and we should otherwise leave things as-is (so: yes to 1, and of the two, option 2b1) but I am willing to entertain arguments in any direction. Convince me!

Flat | Top-Level Comments Only

I'm in favour of 2b1. 2b2 has all the obvious issues of people using future-dating to have multiple sticky-style posts; I think getting rid of that functionality would be An Issue.

I find this helpful and still a feature because I mess with the posting time a fair bit to deal with my OCD. I have a thing that means I must post every. single. calendar. day. So if I start posting at 12.01 on 22nd, I tweak it to 23.59... but sometimes I forget to actually change the date on that back to 21st too, meaning I get prompted the next day when I post on time that I'm trying to post in the past. Being reminded to sort that out by this feature is helpful to me.

I'm aware that it's a really individual use-case that probably no one else has. I'd be in favour of maybe another solution that pops up a prompt saying "you're trying to post this in the past, are you sure?" that then still allows people to post if they want, but again, I'm not sure how many would find that useful. All in all, I am not really opposed to change as long as I can still edit the displayed date

What would this do for reading lists? Would it be community-ish, in that anything posted on 2014-04-21 would be grouped together even if some of it's dated 'yesterday' and some of it's dated 'tomorrow'? (I actually don't know how reading lists sort entries, but I assume it's by server time, so this would just make it possible to purposefully post in the past and still have it show up if someone wanted that, right?)

Also, and maybe more importantly, what would this do for crossposting to sites that haven't gotten rid of the backdating 'feature'?

Edited (clarity) 2014-04-21 13:37 (UTC)

Reading list sorts by server time, always has, so no changes there.

I suppose getting rid of this would risk problems while crossposting, yeah.

Well, except that you could purposefully post from 1970 to your subscribers' reading lists if you really wanted to for some reason. (And I'm sure if it were possible, somebody would find a use for it.)

That said, I think if this gets changed after the emailed-entries-have-wrong-time issue is fixed, it shouldn't affect crossposts too often, unless someone has a different timezone on crosspost-receiving accounts, and I don't imagine that's all that common. (Probably about as common as posting-time shenanigans that don't involve emailing entries.)

The traditional workaround when wanting to make an entry that shows up on the friends page but with a different date deep in the past, is to initially post it at present-date, and then edit it to the desired timestamp. I wonder if making the crossposter try that trick would be too much of a problem? (It probably would be.)

I didn't know that would work, so it's a thought, at least, though it doesn't help if you've inadvertantly posted from the future (as opposed to purposefully, to have multiple sticky-ish entries) and present-date is the past.

The new entry page has a checkbox for "Use the time when entry is posted", which I assume means to use the system time received (2a). I think this should be added to the old entry page and checked by default on both the old and new pages. Then we can safely turn off the in-the-past check and keep things as-is (2b1), because anyone who would be posting with a time in the past would have to had chosen it explicitly.

People posting from clients wouldn't have their client's defaults changed, especially not people who never want the time the entry is posted with to be updated to the system time and who would have specifically saved the "never ever do this to my entries" setting in their client.

People who expect that the entry page won't do that to their entries (because it doesn't do it for them now - I actually don't know what the default is) would be surprised at best if the entry page started doing it to their entries.

The way I'd picture it would be that clients would keep the old behavior, and the defaults would just change for the web interface. I would say that we could encourage client maintainers to switch to the new system, but that presupposes the existence of client maintainers. :P

But you have a point about the new behavior--now that I think about it, it's possible that even with normally configured systems the posting page defaults to posting with the time the post started rather than the time that the post was actually submitted, and somebody might like that. So if we were to change it, we'd have to warn people in advance.

I still hold that that's a terrible default behavior and should never have been implemented in the first place, though.

It's been the behavior since the beginning of LJ, though, and people are very used to it.

That's one of the Perpetual Suggestions, in which people who want to change it to using "time when entry is posted" suggest doing so and the people who want it to be "time they started writing the entry" (the existing behavior) beg not to change it. As far as I can tell, it's about 50/50 (I, for the record, am "time I started writing the entry" camp) and when something is that deeply split, we stay with the status quo.

Changing that wouldn't do anything for this problem, though. It still uses the user's computer time, just the user's computer time at the time they hit 'post' rather than at the time they opened the update page.

Changing that wouldn't do anything for this problem, though. It still uses the user's computer time, just the user's computer time at the time they hit 'post' rather than at the time they opened the update page.

If you used the time posted then you could use the DW system time posted, and you wouldn't even have to have the user submit a time in the form. Though it's a moot point, since we're not going to change it.

I am on board with yes-to-1 and 2b1. I think that solves the issues we see with backdating causing problems while keeping existing workflow to reduce user confusion.

1: No. Well, sort of...
In the interests of preventing accidental stupidity (cuz I have done this) which results in the specified time being not at all in touch with reality or intent, my first thought is to turn the current check into an "Um, you sure, boss?"* check. Said check would land you on a "Timestamp Funkiness Detected, Are You Sure You Wanna Do That?"* page, with a "Just post it already"* button and "Oops, I screwed up, lemmie go fix that"* link/back button/whatever.

Second string preference would be 2b1.

*Said text would only directly apply for the Snark-ese translation of DW, of course...

This was my thought too. If the user, on being told "this looks funny, and if you go ahead it'll be displayed as X" wants to go ahead, there seems no reason to stop them.

If we're not making this obligatory, possibly this could all be done with client-side JS-based validation (if we don't care too much about users who aren't using JS not getting the warning)

"This will make your entry show up in January 1970 rather than April 2014 on your Recent Entries page, but it will still appear on your subscribers' Reading Pages, unless you select 'don't show on reading page'. Additionally, this entry will be crossposted with 'don't show on reading page' checked, and you will not be able to uncheck that on the other site(s). Post anyway?" would work for the "I am posting this from the paaaast!" side of things, but wouldn't help if you accidentally posted from the future and didn't realize until your next entry failed to crosspost.

That works great from the page, but not so much so from something like email. Great minds and all; I think the solution is the inbox.

Pretty much my thinking on the matter as well.

IMO we can kill it dead (2b1).

2b2 for me, at least as an option. I would love to see everything in one time series rather than having to guess where people are, geographically, at that moment.

Well, 2b2 isn't something that would address that -- I'm talking about the order in which entries are displayed when you view someone's Recent Entries page, not the time that is displayed on the entry (such as when you see it on your reading page).

It's the difference between "if I post an entry right now dated 1999-01-01, it will display on my Recent Entries page on the top of my journal" vs "if I post an entry right now dated 1999-01-01, it will appear on my Recent Entries page behind all the entries dated after it".

Yes, and 2b1.

I use past-dating to post things that happened on paper/etc to the day when they actually happened. I have a slow-going project to put my paper journals in here so they're all in one place. ~~2b2 would break the hell out of that.~~ ... oh, right, recent page only, rather than the archives.

In the event of something more than, say, 48 hours off server time, I propose something like an inbox notification, in a classification by itself so people can go through and make it vanish in one fell swoop if it bothers them: a notification that on [server timestamp], their entry [title and link] was posted with a [manual timestamp] -- in case it goes very odd and they're not sure where it went.

Edited 2014-04-22 07:23 (UTC)

With 2b1, how does this scenario play out for the reading page?
Say:
Ten minutes ago I made post A dated at the point I made the post.
I now make another post, B, dated 11 minutes ago.
When someone looks at their friends list, do they see both posts, in reverse-posted-date-order or just post A?

Basically, will the new functionality remove the very concept of the "posting in the past" option or will it keep the current concept, but automatically tick the "Post in the past" button for you?

They would see both posts in the order that it was received by the server, with the user-supplied date and time -- basically, exactly what happens when you have a community on your reading list and someone posts from London with a date of 2014-04-22 0733 BST and then someone else posts from San Francisco with a date of 2014-04-21 2333 PST. The 2014-04-21 2333 PST post appears on top, since it was received by the server second, and then the 2014-04-22 0733 BST appears underneath it, but both are time/date stamped with the user-supplied time.

This proposal would remove the need to check the 'post in the past' box and turn it purely into 'don't show on reading pages'. (That checkbox does two things: allows someone to post in the past, and does not show entries on reading pages (so that people importing large numbers of entries, either by using our importer or because they're "filling in" old entries like azurelunatic references, don't flood their subscribers' reading pages). That binding-together is kind of conceptually awkward and hard to explain sometimes; this proposal would eliminate the need for the first, and make it purely the latter.)

Gotcha, that makes sense.

In that case 2b1 makes the most sense to me.

(I'll still be setting dates/times myself, because I crosspost. But eventually LJ might work this one out too...)

I think it causes more pain than it solves, in terms of having to explain what dated out of order is, dealing with the confusion when people get it the wrong way around (I had it wrong for such a long time, still hesitate when I see the checkbox what does it *mean*, etc).

Let's get rid of it; 2b1 sounds reasonable, just assume that we post things out of order.

Hmm. The only aspect of the dated out of order that I'm not sure we've talked about: how does it play out for entries you don't want to show on the recent entries page? Do we settle on just one behavior for that? (actual time posted, vs display time?)

What do you mean by "entries you don't want to show on the recent entries page"? I can't think of any way you'd do that. (Unless you mean the trick of posting an entry and then editing it to a date of like 1970-01-01, which is not a trick I think anybody but the most hardcore power users knows about.)

Sorry I was thinking reading page! And you just answered that question in a comment to someone else :)

Hee, okay :)

OH DEAR GOD YES PLEASE GET RID OF THIS :-)

I haven't encountered the posting-by-email problem, probably because I am lucky enough to usually be within an hour of UTC, but there are two other use cases that have caused me to swear at it in the past,

Travelling between time zones
Drafting a long and complicated post in one tab; opening another tab to fire off a quick post; finding that the long and complicated post won't, er, post, as it's "in the past".

As an additional benefit, this would make the "allow dating out of order" checkbox a lot less confusing. We would probably want it retained, as there are probably reasons that people would want to make posts without showing them on reading lists, but it could have a simple and straightfoward explanation for what it does (not showing things on reading lists) rather than one that caused me, at least, a lot of head-scratching.

I favour option 2b1. In the long run (and this could be implemented seperately) I think we could get rid of the whole "Edit date" step and just start off with an editable date, pre-populated with the current time.

I agree that on today's internet, if your clock is wonky you will probably have bigger problems than oddly-dated DW posts. If we're wrong about this, there is a solution that doesn't require keeping the check - but, it does involve getting time zones right.... that is to load the compose page with an edit date field that is pre-populated with the current time *from the server*, adjusted for the user's stated time zone.

Edited 2014-04-24 06:03 (UTC)

I'm a little confused about 2a) - isn't using the server time for the 'are you trying to post in the past' check effectively just removing the check entirely, as per 1)?

As for the LJ web interface to the code being down - it's not just the web interface, the entire SVN interface is down. :( I'm not sure how long it's been that way.

A while apparently--see this post here, if you want refs.

Flat | Top-Level Comments Only

Can anyone make me a strong argument for keeping "you are posting in the past" checks on updating?

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

Please add an option to reenable spacebar heating

Re: Please add an option to reenable spacebar heating

Re: Please add an option to reenable spacebar heating

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject