.NET DirectoryServices查找方法使用UTC还是本地时间？

，则

UserPrinciple

和

ComputerPrinciple

类的查找方法（如FindByLogonTime和FindBybadPasswordEntry）使用UTC时间过滤结果。然而，测试表明这些方法似乎将本地时间作为输入，而生成的对象使用UTC作为其时间属性，需要转换为本地时间

下面的示例似乎正确列出了自当地时间早上6点以来在服务器上尝试登录失败的所有用户：

    static void Main()
    {
        var pc = new PrincipalContext(ContextType.Domain, dcServer);
        PrincipalSearchResult<UserPrincipal> uFailed = UserPrincipal.FindByBadPasswordAttempt(pc, DateTime.Now.Date.AddHours(6), MatchType.GreaterThan);
        string s = "";
        foreach (UserPrincipal u in uFailed)
        {
            s += u.SamAccountName + ": " + Convert.ToDateTime(u.LastBadPasswordAttempt).ToLocalTime().ToString() + "\r\n";
        }
        Console.Write(s);
        Console.Read();
    }

static void Main（）
{
var pc=新的PrincipalContext（ContextType.Domain，dcServer）；
PrincipalSearchResult uFailed=UserPrincipal.FindByBappassword尝试（pc，DateTime.Now.Date.AddHours（6），MatchType.greaterth）；
字符串s=“”；
foreach（uFailed中的用户主体u）
{
s+=u.SamAccountName+“：“+Convert.ToDateTime（u.LastBadPasswordTest）.ToLocalTime（）.ToString（）+”\r\n”；
}
控制台。写入；
Console.Read（）；
}

请注意LastBadPasswordAttract属性的UTC转换，但不在FindByBadPasswordAttract筛选器中

---

在不知道我是否遗漏了什么（可能）或MSDN文档是否错误的情况下将其投入生产时，我很紧张。代码在其查询的DC上运行，因此应该没有时区问题。

MSDN文档是准确的，您只需要注意传入的

日期时间

值的

.Kind

属性

如果深入研究引用源或反汇编，您会发现您要传递的

DateTime

值最终会被传递到，这在其行为中考虑了

种类

因此，您可以基于
DateTime.UtcNow
传入一个值，该值的
.Kind
值为
DateTimeKind.Utc
，并且该值可以工作，或者，您可以像当前一样执行并传递
DateTime.Now
，它的
.Kind
为
DateTimeKind.Local
，并且该本地时间将在查询之前转换为UTC。只需确保您认识到这是运行代码的计算机的本地时间。如果这可能与您的用户不在同一时区，则您可能需要使用
TimeZoneInfo
获取与其他一些本地时区相当的UTC时间

如果出于某种原因，您决定传入一个您自己构造的日期，它可能会有
DateTimeKind.Unspecified
。对于此特定函数，它将被视为UTC。这并不一定适用于所有日期/时间函数，因此要小心

另外，在输出中，当您使用的值已经是
DateTime
时，不需要调用
Convert.ToDateTime
。因此，在这段代码中，您甚至不需要
ToString
，除非您计划传递一个格式说明符。同样，如果您的用户可能在其他时区，请不要使用
。ToLocalTime
，而是使用
时区信息
上的方法之一进行转换

另一个小优化是，如果您愿意，可以使用
DateTime.Today
而不是
DateTime.Now.Date
。（除了可读性稍高之外，没有什么区别。）
很抱歉耽搁了您的时间，感谢您的帮助——这有助于我了解发生了什么，欢迎并感谢您提供的提示。没问题。很高兴我能帮忙！