26

Microsoft Office 365 saves information in the registry about what time it last searched/downloaded/applied updates in a format like this:

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\office\ClickToRun\Updates' | select *time

UpdateDetectionLastRunTime      : 13335538464958
UpdatesAppliedTime              : 13335413795690
DownloadTime                    : 13335365916104
UpdatesDiscoveryPeriodStartTime : 13259087464032
UpdatesBlockedTime              : 0

What is this format, and how does it convert to a standard date/time?

Improve this question
4
  • Related: superuser.com/questions/592782/…
    – Mokubai ♦
    Aug 3 at 20:29
  • 8
    Not related because those certainly aren’t Unix timestamps of any kind, unless OP is from the 24th century.
    – Daniel B
    Aug 3 at 20:32
  • 4
    @DanielB sadly I believe it is related, but you have to compensate for the fact that Windows Epoch time starts in 1601 and subtract 369 years (1970 (unix epoch) - 1601 (windows epoch)) from the value you get from an online timestamp converter. That gives a time sometime correct-ish.
    – Mokubai ♦
    Aug 3 at 20:38
  • @Mokubai - The Windows epoch time, of course, begins in 1601 because of the three missing centuries that were removed from the calendar by the Holy Roman Emperor Otto III. Note that although Heribert Illig posited that 297 years were removed, the article actually notes that the true period is 369 years. Needless to say, 1601+369=1970, the beginning of the Unix epoch. Unix continues to perpetuate this fraud, but Windows refused to bow to conventional history! And now you know.
    – Obie 2.0
    Aug 6 at 4:55

2 Answers 2

Reset to default
37

These numbers are timestamps since Windows Epoch Time which starts at January 1, 1601, counting in millisecond intervals.

From the Microsoft page How to convert date/time attributes in Active Directory to standard time format:

Active Directory stores date/time values as the number of 100-nanosecond intervals that have elapsed since the 0 hour on January 1, 1601 until the date/time that is being stored.

The above page describes the built-in win32tm command, that can do this conversion for you. As your Office times are stored in milliseconds and this command requires nanoseconds, we need to append 4 zeroes to the end of your values to get the "full" 18-digit timestamp code:

w32tm /ntte 133355384649580000
154346 12:14:24.9580000 - 03/08/2023 13:14:24

As the full 18-digit value is using 100ns time intervals since Windows Epoch, by removing 4 digits from the end you reduce the precision down to millisecond intervals from 100ns intervals. You'll probably never notice this reduction in precision.

You can validate converting from the number you have using online converters such as LDAP, Active Directory & Filetime Timestamp Converter but again you will need to add four 0s to the end of the string to get the correct 18-digit value.

Improve this answer
2
22

To add to @Mokubai's answer, the way to do it in PowerShell, which I assume is desired here, would be to use FromFileTime function, e.g.:

$time = 13335538464958
$dateTime = [DateTime]::FromFileTime($time * 10000)

This uses local time, there's also FromFileTimeUtc that uses UTC time instead.

Improve this answer
1
  • 4
    Nice. I was editing to give a more authoritative source and a windows command that does the conversion as well.
    – Mokubai ♦
    Aug 3 at 21:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .