Meanings of e-mail timestamps in MS Outlook VBA

huangapple go评论68阅读模式
英文:

Meanings of e-mail timestamps in MS Outlook VBA

问题

为了在MS Outlook VBA中处理电子邮件,需要了解每封电子邮件发生的特定事件的时间,例如发送时间、接收时间等。Outlook似乎为此目的提供了四个时间戳,它们是邮件项对象的属性,其中三个具有相应的Messaging API(MAPI)属性:

邮件项属性 MAPI属性 描述
SentOn PidTagClientSubmitTime 发送时由发件人系统设置。
ReceivedTime 接收时由接收系统设置。
CreationTime PidTagCreationTime 电子邮件记录首次存储在Outlook中的时间。
LastModificationTime PidTagLastModificationTime Outlook中记录最后修改的时间。

上述描述是我从给定链接中阅读文档后的简要总结。根据这些描述,上面的表格通常应该按照时间顺序排列,即每个时间戳通常应该等于或晚于前面列出的时间戳。在分析了跨两天发送和接收的107封电子邮件后,我发现以下情况:

  • 收件时间与发件时间之间的差异:
    • 对于我发送的电子邮件,接收时间应该为null,因为我的系统无法知道电子邮件何时接收,甚至是否接收。但实际上,接收时间总是等于发送时间。这在逻辑上是错误的,但至少在内部是一致的。
    • 对于我接收的电子邮件,这应该始终是正数且相当小的。
      • 差异有时会达到两分钟为负值。虽然看似不合逻辑,似乎意味着电子邮件在发送之前已被接收,但这可能是由于发送和接收系统的时钟不同步造成的,这很容易发生。
      • 差异通常在零到十分钟之间,这是应该的。零似乎表示传输速度非常快。
      • 差异有时在一到七小时之间。电子邮件需要这么长时间到达似乎令人惊讶,但几乎所有这些情况都是垃圾邮件,所以我猜测发件人可能连接缓慢或其时钟设置错误。

上述情况都是有道理的。但是当我查看创建和修改时间时,有一些令人惊讶的地方:

  • 创建时间与接收时间之间的差异:
    • 对于我发送的电子邮件,这总是零或负值,因为Outlook在发送之前将电子邮件记录为草稿。然而,根据我的习惯,我经常起草电子邮件,然后让它们在发送之前停留数小时甚至过夜以供审阅。但在我检查的两天电子邮件中,我发送的电子邮件的这种差异从未超过一小时,所以似乎存在某种问题。
    • 对于我的系统发送给自己的维护电子邮件,这个差异是正数,介于几分钟到40分钟之间。这似乎很奇怪,因为它们似乎应该是瞬间完成的。
    • 对于我接收的电子邮件,这个差异应该始终是正数,我认为应该非常短,如不到一秒。但实际上,它很少少于一分钟,通常是几小时,甚至多达22小时。这些长时间的延迟最多且最常见于垃圾邮件,这很奇怪,因为我不使用自动垃圾邮件处理,而是手动将垃圾邮件移动到垃圾邮件文件夹,所以它们的处理时间不应该与其他电子邮件有任何区别。

这些观察结果是在我运行MS Office LTSC Pro Plus 2021的计算机上进行的,该计算机运行在Windows 11 Pro 64位操作系统上,都已经安装了最新的更新。

这些令人惊讶的情况表明,我在上面表格中的描述可能不准确。是否有人能解释这些时间戳的真正含义?正确理解它们的算法定义将有助于编写有效处理电子邮件的代码。

英文:

In order to work with e-mails in MS Outlook VBA, it's necessary to know the times that certain events occurred for each e-mail, such as when it was sent, when it was received, etc. Outlook appears to have four timestamps for this purpose, which are properties of the MailItem object, three of which have corresponding Messaging API (MAPI) properties:

MailItem property MAPI property Description
SentOn PidTagClientSubmitTime Set by sender's system when sent.
ReceivedTime Set by receiving system when received.
CreationTime PidTagCreationTime When the record of the e-mail was first stored in Outlook.
LastModificationTime PidTagLastModificationTime When the record in Outlook was last modified.

The descriptions above are my brief paraphrase of what I read in the documentation at the given links. According to these descriptions, the above table should usually be in chronological order, i.e., each timestamp should usually be equal to or later than the one listed before it. On an analysis of 107 e-mails sent and received over a span of two days, I find the following:

  • The difference between the time received and the time sent:
    • For e-mails I sent, the received time should be null because my system cannot know when, or even if, the e-mail was received. But instead, the received time is always equal to the sent time. This is logically flawed, but at least it's internally consistent.
    • For e-mails I received, this should always be positive and fairly small.
      • The difference is sometimes up to two minutes negative. While appearing to mean illogically that the e-mail was received before it was sent, this can be caused by the clocks of the sending and receiving systems not being in synch, which can easily happen.
      • The difference is usually between zero and ten minutes, which is what it should be. Zero appears to indicate lightning fast transmission.
      • The difference is sometimes between one and seven hours. It seems surprising that e-mails would ever take that long to arrive, but almost all these cases are on spam e-mails, so I'm guessing that the senders are either on a slow connection or their clocks are set wrong.

The above all make sense. But there are several surprises when I look at the creation and modification times:

  • The difference between the creation time and received time.

    • For e-mails I sent, this is always zero or negative because Outlook stores a record of the e-mail as a draft before it is sent. However, the difference should often be very large because I often draft e-mails and let them sit for hours or overnight for review before sending. But in the two days of e-mails that I checked, this difference for e-mails that I sent is never more than an hour, so there seems to be something wrong here.
    • For maintenance e-mails that my system sends to itself, this difference is positive and between a few minutes and up to 40 minutes. This seems strange because it seems that these should be instantaneous.
    • For e-mails that I received, this difference should always be positive and I would think it should be very short, like less than a second. But:in fact, it is seldom less than a minute and is often several hours, even as much as 22 hours. These long delays are longest and most frequent for junk e-mails, which is strange because I don't use automated junk handling but manually move junk e-mails to a junk folder, so their processing times shouldn't be any different from other e-mails.
  • The difference between modification time and creation time:

    • For e-mails that I sent, this should always be positive and should often be large because of changes I make long after the draft is first saved. It should usually be shorter than the (negative) difference between the creation and sent (=received) times because I can't change an e-mail after it's sent except by deleting an attachment. But it seems that this difference is actually usually longer than the creation/sent difference, and I don't understand why.
    • For e-mails that I received, this should usually be zero, but can be positive and of any size if I deleted an attachment. That is consistent with what I see.

These observations were made on my computer running MS Office LTSC Pro Plus 2021 under Windows 11 Pro 64, both with the latest updates.

These surprises suggest that my descriptions in the above table are not accurate. Can someone explain what these timestamps really mean? A proper understanding of their algorithmic definitions would help in writing code to effectively manipulate e-mails.

答案1

得分: 0

总的来说,时间预计会有偏差,有时候会出现令人意外的情况。请记住,没有绝对的时间源。日期/时间戳来自本地时钟(在PST或缓存的OST Exchange邮箱的情况下)、远程Exchange服务器以及您的电子邮件通过的邮件服务器。

还要记住,Exchange有时会毫无明显原因地修改消息 - 它可以运行一些异步过程(例如实体提取)并在以后的某个时间点更新消息。当消息在文件夹之间移动时也可能会出现问题 - 这算作修改吗?创建时间应该是来自原始文件夹的时间吗?等等。

英文:

In general, the times are expected to be off, sometimes in surprising ways. Keep in mind that there is no the ultimate time source. the date/time stamps come from the local clock (in case of PST or cached OST Exchange mailboxes), remote Exchange server, and the mail server your email comes through.

Also keep in mind that Exchange can modify messages seemingly for no good reason - it can run some asynchronous processes (such as Entity Extraction) and update the messages at some later point. There can also be issues when a message is moved between folders - does that count as modification? Should the creation time be that from the original folder? Etc.

huangapple
  • 本文由 发表于 2023年5月18日 01:54:27
  • 转载请务必保留本文链接:https://go.coder-hub.com/76274942.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定