20200806212121 PageTitle is a valid page title, so maybe we'd use a pipe character since that can't be used in titles, e.g. 20200806212121|PageTitle. This is something I think we wanted to do, it's just difficult to pull off in a user-friendly way. Some questions:

• How would indefinitely watched items be presented? Would it have to explicitly state infinity instead of a timestamp? If an expiry is omitted, does that mean once the form is submitted we should watch indefinitely, or leave the current expiry untouched?
• What do we do about invalid expiries, if anything? Should we strip them out, making them indefinite? Or keep the original expiry, if there is one? How should errors be presented to the user (there could be thousands)?
• What if the user accidentally put 20200806212121Foo, forgetting the pipe character? This wouldn't produce an error since that's a valid title, and they may have just unknowingly unwatched Foo.

Overall, I wonder how intuitive it would be to use the raw watchlist as a means to edit expiries. Carefully going title by title, ensuring you have the right syntax and a valid expiry seems a bit tedious for the average user. The normal Special:EditWatchlist is used significantly more, so it may be worth putting focus there first for mass-editing of expiries.

Short-term I think using the API is probably the most practical solution, depending on the use-case. For instance it would be trivial to write a script to set the same expiry for a given list of pages.

I wasn't trying to be prescriptive in the format - and raw editing is usually more of a 'power editor' option. Right now it appears that the expiring data is completely lost if you use the raw editor though to do bulk changes (as it isn't included in the data feed) - so if you copy out thousands of rows and want to restore them you loose the existing expiries.

Right now it appears that the expiring data is completely lost if you use the raw editor though to do bulk changes (as it isn't included in the data feed) - so if you copy out thousands of rows and want to restore them you loose the existing expiries.

If you remove titles and submit the form, the expiries for those titles are of course lost (you unwatched them). However expiries for any preexisting titles should remain in tact. If you are seeing otherwise please let us know! We can make this behaviour more clear with some messaging, if we feel that's needed. I would assume removing and re-adding isn't a super common task, though.

It's not clear to me that:

1. There is a way to do this that isn't going to be confusing to most users.
2. That the use cases for the raw watchlist even necessitates handling expiries.

The purpose of the raw watchlist interface is bulk adding or bulk removing pages from your watchlist. Neither of those uses would be affected by just leaving the interface how it is. Bulk removing and then bulk restoring pages with expiries is a vanishingly small edge case and I don't think it would make sense to complicate the interface for that specific case. The only use case that I think might justify complicating the interface is bulk addition of pages with expirations. But even then, I have to wonder if the trade-off of potentially confusing users with a novel mark-up system is worth the benefit.

I could see easily using bulk editing of the list to add/modify expiries - but I may be an edge case