Windows的本地时间(LocalTime)、系统时间（SystemTime）、格林威治时间(UTC-Time)、文件时间(FileTime)之间的转换...

 

　　今天处理了一个Bug，创建历史数据时脚本函数的起始时间不赋值或者赋0值时，计算引擎推给历史库的UTC时间为-288000000000，一开始以为是bug，经过分析后发现不赋值默认给起始时间赋0值，而此时的0值是localTime的1601年，比格林威治时间快8个小时，而存入历史库的时间是标准的格林威治UTC时间，因此会出现-288000000000这样的情况。

　　首先，先从简单的说起，本地时间(LocalTime)，也就是系统设置时区的当前时间！比如说当前系统设置的时区为“(UTC+08:00)北京，重庆，香港特别行政区，乌鲁木齐”（东八区），系统的右下角通知区域显示的时间为“2012/5/18 16:57”，那么这个时间就是当前系统的本地时间！

　　要说清楚什么是系统时间（SystemTime）之前先来了解一下格林威治时间。本初子午线被定义为通过格林威治经线的位置，相对这条经线的时区向东递增，向西递减，每隔一个时区，相差一个小时。那么，上面例子中的东八区的时间就是相对于格林威治时间加上了八个小时！而Windows的系统时间是就是格林威治时间！知道了这一点，本地时间与系统时间之间的转换也就很容易了。将上面的本地时间“2012/5/18 16:57”转换到系统时间只要减去八个小时就行了！转换结果为“2012/5/18 8:57”。

　　本地时间与系统时间的都是用SYSTEMTIME结构来存储的，关于这个结构参见MSDN。

　　文件时间(FileTime)的存储方式则与本地时间、系统时间有些不同，它使用64位的数据长度存储。引用MSDN上面的一句原话“A file time is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated Universal Time (UTC).”这个64位的值记录了自1601年1月1日0点以来的以100纳秒（ns）为单位的格林威治时间间隔，注意，是纳秒，不是毫秒！将这个数据转换为秒的话要除以10^7（1秒 = 10^9纳秒，这里是100纳秒单位）！了解了上面的格林威治时间，理解这个很容易！

　　本地时间与系统时间之间的转换上面已经说了，这其中的转换因子就是当前系统的时区，也可以通过SystemTimeToTzSpecificLocalTime、TzSpecificLocalTimeToSystemTime两个函数来完成，这两个函数在转换时都要指定时区信息，具体用法参考MSDN。下面谈谈系统时间与文件时间、本地时间与文件时间之间的转换。因为用到文件时间的地方不仅仅限于记录文件的创建、修改时间。而且还可以通过文件时间的转换函数来完成系统时间与本地时间的转换！

　　1. 系统时间与文件时间的转换：SystemTimeToFileTime、FileTimeToSystemTime
　　2. 本地时间与文件时间的转换：LocalFileTimeToFileTime、FileTimeToLocalFileTime

　　从上面可以看出，本地时间与系统时间的转换也可以通过文件时间来完成。这里需要注意一点的是，本地时间和文件时间都是对于当前系统的时区而言的，这样会出现同一个文件放到不同时区的系统中时，文件的创建时间，修改时间等等都会不一样。因为文件创建时间，修改时间等都是以文件时间方式记录的，操作系统在将文件时间转换为本地时间时要根据系统当前的时区作为参考。所以，在系统时间与本地时间之间转换时最好的方式是采用文件时间函数，这样时区的问题会由操作系统解决。此外，还有一些函数使用的数据结构中也用到了文件时间，比如用于检索系统定时信息的GetSystemTimes的参数、查询系统时间信息时用到的NtQuerySystemInformation中的SYSTEM_TIME_INFORMATION结构，都是给出的文件时间！知道了这一点，将它们转换为本地时间就很容易了。

转载于:https://www.cnblogs.com/wjcoding/p/10985506.html