Первая подсказка - это разница во временных метках: они на расстоянии 3600 секунд или, другими словами, один час.Я предполагаю, что в игру вступает проблема перехода на летнее время.
Вы можете увидеть, что это применяется DateTimeOffset, посмотрев свойства объекта.Использование его в Powershell:
$t = [datetime]::Parse("1932-10-22")
new-object system.datetimeoffset($t)
дает вывод:
DateTime : 22/10/1932 00:00:00
UtcDateTime : 21/10/1932 23:00:00
LocalDateTime : 22/10/1932 00:00:00
Date : 22/10/1932 00:00:00
Day : 22
DayOfWeek : Saturday
DayOfYear : 296
Hour : 0
Millisecond : 0
Minute : 0
Month : 10
Offset : 01:00:00
Second : 0
Ticks : 609618528000000000
UtcTicks : 609618492000000000
TimeOfDay : 00:00:00
Year : 1932
DateTimeOffset.ToUniversalTimeMilliseconds()
возвращает время Unix из значения UTC даты / времени.
Таким образом, вынужно вместо этого создать DateTimeOffset с часовым поясом UTC, поэтому (снова с PS, но тривиально преобразовать в C #)
$t = [datetime]::Parse("1932-10-22")^C
$ofs = new-object System.Timespan(0)
new-object system.datetimeoffset($t, $ofs)
Дает:
DateTime : 22/10/1932 00:00:00
UtcDateTime : 22/10/1932 00:00:00
LocalDateTime : 22/10/1932 01:00:00
Date : 22/10/1932 00:00:00
Day : 22
DayOfWeek : Saturday
DayOfYear : 296
Hour : 0
Millisecond : 0
Minute : 0
Month : 10
Offset : 00:00:00
Second : 0
Ticks : 609618528000000000
UtcTicks : 609618528000000000
TimeOfDay : 00:00:00
Year : 1932
Теперь это дает миллисекундуотметка времени эпохи -1173744000000, которая отличается от ожидаемого значения.Я проверил несколько источников, в том числе epochconvertor.com, и это, кажется, правильное время.Введенная вами отметка времени -1173747600000 - 21 октября 1932 года в 23:00: 00.