我编写了一个简单的powershell脚本,递归遍历文件树,并以制表符分隔的形式返回每个节点的路径及其创建时间,以便我可以将其写入文本文件并使用它做统计分析:
echo "PATH CREATEDATE"
get-childitem -recurse | foreach-object {
$filepath = $_.FullName
$datecreated = $_.CreationTime
echo "$filepath $datecreated"
}
然而,一旦我这样做了,我注意到脚本产生的CreationDate时间比Windows资源管理器在查看相同文件的相同属性时所说的提前一小时。基于检查我的其余数据集(以不同格式记录周围事件),很明显我从资源管理器获得的结果是唯一符合整体叙述的结果,这让我相信Powershell存在问题使脚写出错误时间的脚本。有没有人知道为什么会这样?
问题背景:
我正在尝试纠正一些XML日志文件设计中的问题,这些文件在用户启动和停止使用应用程序时记录,实际上应该记录用户通过不同阶段所花费的时间工作流程。我找到了一种可能的方法来解决这个问题,方法是从用户发送的一些备份文件中提取日期信息以及XML日志。备份是由我们的最终用户应用程序在用户在工作流中的各个阶段之间转换的时刻生成的,所以我试图将这些文件的时间戳中的信息与原始XML日志的内容一起带出来以确定我想了解工作流程步骤。
评论讨论中提出的要点摘要:
答案 0 :(得分:0)
我从来没有找到PowerShell与资源管理器的时间戳之间的差异的最终技术原因,但我能够通过从powershell脚本中减去所有时间戳的一小时来纠正它。但是,在我这样做之后,我从XML日志文件中获取的时间戳与使用powershell脚本从文件系统中提取的时间戳之间仍然存在很大的分歧。推断最终用户在生成文件时可能停留在同一时区,我写了一个小算法,通过评估工作流程和步骤中步骤1和2之间的中间时间来估计每个用户的时区如果用户的时区出现问题,则这两个时间跨度中的一个将为负数(因为估计了第2步事件的时间,并且从XML日志中了解了步骤1和3事件的时间) 。)然后我将正值向下舍入到最接近的小时,并将该小时数作为该用户步骤的偏移量应用了2次。总的来说,这使我的数据集中的坏数据量从20%下降到0.01%,所以我对结果感到满意。
如果有人需要它,这里是我用来在时间戳中创建小时偏移量的代码(不是powershell代码,这是在处理数据处理的另一部分的C#脚本中):
DateTime step2time = DateTime.Parse(LastModifyDate);
TimeSpan shenanigansCorrection = new TimeSpan(step2time.Hour-1,step2time.Minute,step2time.Second);
step2time= step2time.Date + shenanigansCorrection;
重新定义step2time
变量的原因是DateTimes在.NET中不可变。