# Allow manual overrides of the date header field

[seifferth]

Previously, the date field was always updated when sending the message. While this behaviour is quite reasonable in most cases, there might also be moments when specifying a date different from the system's current local time might come in handy. As it happens, I was just in need of this ability myself at this very moment; hence I implemented this feature. I would be happy if this feature made it into mainline bower. While its use is probably a rare corner case, the feature itself is quite non-intrusive and does not change the behaviour of bower unless a user explicitly adds a date header to the temporary message. Consequently, its existence should be mostly transparent to those who might not want or need it.

As already mentioned, this patchset introduces the ability to manually override the date field. This is done by simply adding a 'Date' header when composing a message. Once this header is added, bower will use the user-specified date value instead of automatically generating one from the current system's time settings. With the last commit, this behaviour is even persisted across the postpone-resume cycle. To return to the automated setting of the message date, a user would only need to remove the date value (or the whole line) when editing the message. If a user does not manually add a date header line at some point, the changes introduced in this patchset should not affect their usage of bower at all. The feature is not (yet) documented, but I believe that it is quite straightforward; it was even the first thing I tried to do myself before (disappointedly) realising that the date value is always overridden with the system's current local time.

Drawbacks / Open issues

• In order to persist the information on whether a date value was set automatically or manually, a new header field was introduced. This field is called 'X-Bower-Metadata' and is handled as a special case when parsing messages. When parsing postponed messages, the existence of and information in X-Bower-Metadata will be used to indicate whether the date value should be retained or whether it should be cleared. While I believe that having this field for persisting information across the postpone-resume-cycle comes in handy, its design was pretty ad-hoc and the implementation probably still has a number of rough edges that would need to be resolved if the field should ever be used for more than storing a single boolean value. Having said that, the field is currently designed as a simple semicolon-separated list of strings that might have some kind of special meaning for bower. This should make the design both reasonably flexible and reasonably simple for further extensions.
• The use of this patchset made another issue apparent: When a message is resumed, edited, saved without modification and then postponed again, it disappears. This is apparently due to the fact that notmuch will treat the new version as a duplicate of the old one, while bower, having inserted the new version, marks the old version as deleted. As, prior to the introduction of manual overrides, the date of postponed messages was always updated upon insertion into the notmuch database, the case where two messages have both the same date and the same contents did not come up in actual usage. While this bug is annoying, however, I do not believe that the proposed patchset is to blame for it. Currently, my personal solution for dealing with this bug is to take special care when postponing messages containing manual date overrides; and to search the messages marked as deleted when I forget.

[wangp]

Drawbacks / Open issues

• In order to persist the information on whether a date value was set automatically or manually, a new header field was introduced. This field is called 'X-Bower-Metadata' and is handled as a special case when parsing messages. When parsing postponed messages, the existence of and information in X-Bower-Metadata will be used to indicate whether the date value should be retained or whether it should be cleared. While I believe that having this field for persisting information across the postpone-resume-cycle comes in handy, its design was pretty ad-hoc and the implementation probably still has a number of rough edges that would need to be resolved if the field should ever be used for more than storing a single boolean value. Having said that, the field is currently designed as a simple semicolon-separated list of strings that might have some kind of special meaning for bower. This should make the design both reasonably flexible and reasonably simple for further extensions.

I think the design is okay.

• The use of this patchset made another issue apparent: When a message is resumed, edited, saved without modification and then postponed again, it disappears. This is apparently due to the fact that notmuch will treat the new version as a duplicate of the old one, while bower, having inserted the new version, marks the old version as deleted. As, prior to the introduction of manual overrides, the date of postponed messages was always updated upon insertion into the notmuch database, the case where two messages have both the same date and the same contents did not come up in actual usage. While this bug is annoying, however, I do not believe that the proposed patchset is to blame for it. Currently, my personal solution for dealing with this bug is to take special care when postponing messages containing manual date overrides; and to search the messages marked as deleted when I forget.

We might just need to generate a unique Message-ID for the draft message.

At some stage we should write a proper Date header parser.

[seifferth]

We might just need to generate a unique Message-ID for the draft message.

That might solve the issue. I didn't look into the Message-ID handling of postponed messages yet. Does bower actually use the same Message-ID during postpone-resume-postpone?

At some stage we should write a proper Date header parser.

Seeing that user-specified dates are currently treated as strings, this might be an option. Having a Date header parser would also allow us to align the Message-ID with the user-specified date rather than with the system's current time setting. On the other hand, treating user-specified dates as strings gives users more flexibility than a date parser could offer. It also gives them the option to shoot themselves in the foot quite easily; but seeing that the manual date override is quite an advanced as well as a somewhat hidden feature, I figured that this might be ok. Keeping the user-specified date as a string also offers users the ability to experiment with malformed date values. I am not sure whether there is a strong use-case for this, but it is a flexibility that a date parser would probably impede.

[wangp]

Sorry for the delay. Bower generates draft message files without Message-IDs right now.

I'm not sure what reason there would be for flexibility in the Date field. I don't like the idea of sending out malformed messages if we can help it.

[seifferth]

Bower generates draft message files without Message-IDs right now.

Well, in that case introducing them might just solve the issue. I might look into this once I find some time.

I'm not sure what reason there would be for flexibility in the Date field. I don't like the idea of sending out malformed messages if we can help it.

As I said, this is probably not a strong use case anyhow. I was just thinking that I might use this for debugging purposes; like to check how notmuch handles malformed date headers, for instance. But then I can always just pipe any manually created message into notmuch-insert or msmtp or such. So if you want to write a date header parser, feel free to go for it. I myself am mostly using date -R to create the manual date overrides anyhow, so I am already quite confident they are well-formed.

[wangp]

Merged manually.