feature request: FILETIME support and milisecond epoch time support

[mzpqnxow]

Hello,

First, thanks for dateutil, it is by far the best package I've ever used for parsing dates "the right way" without doing much thinking. I often deal with large datasets from third party APIs who take liberties with standard formats, and it is terrific for saving me time.

With that said, it would be great if dateutil could recognize and parse Microsoft FILETIME format, which are most commonly represented by 64-bit integers. This date format is seen commonly in some Active Directory objects (both user and computer objects have some attributes in FILETIME) and is used as a timestamp on files, apparently (I don't work with Windows much, believe it or not)

FILETIME is a proprietary 64-bit number constructed using milliseconds and based on a special (non-UNIX) epoch- 1601 instead of 1/1/1970. Microsoft describes it as "Contains a 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601 (UTC)."

So basically, annoying, but used a lot if you're developing in an AD environment. It's not a difficult implementation, but it would be really nice to have this functionality in dateutil

There is an example 3 line implementation (here)[https://gist.github.com/Mostafa-Hamdy-Elgiar/9714475f1b3bc224ea063af81566d873] though I can't comment on how robust it is. Because the number involved are 64-bit it might be wiser to implement using numy or similar. For convenience, there's a trivial converter available here for testing or investigating

For those of you that come from a C background, this is much easier to understand

As an aside: I'm not sure that you wants to get into the business of interpreting "special" values in dates, but in my implementation, I handle the special value 2^63-1 as a None value

I would be happy to add my implementation (after switching to proper strong datatypes) if it is something the project would be interested in.

Also, I'm sorry to mix two issues, but they are kind of along the same lines. MSFT AD also likes to store "milisecond epoch" time- basically UNIX epoch time, but as miliseconds since 1/1/1970. I have a simple implementation for this (that I would want to clean up after looking through the standards of the project) and also would like if it would be considered for inclusion.

If this is a strict no, I'd like to know the reason, I admittedly did not read much about the project aside from the contributing guidelines, so apologies if this is not proper protocol for feature requests.

Thanks again, let me know and if this is something desired, I'll bang out the PRs once I get a feel for the state machine in the dateutil parser (I think I recall seeing a proper state machine somewhere in there...)

[ghost]

see also/possible duplicate of #355

[mzpqnxow]

Exact dup. My mistake, I searched and did not see it.

…

On Fri, Aug 17, 2018 at 08:02 Wagner ***@***.***> wrote: see also #355 <#355> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#804 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHpRZP9Rp9ZFk8xjuoPUsoa1qVogK8Cfks5uRrDagaJpZM4V-3vA> .

[ghost]

I also didn't know if the name of the time format is correct or what it is actually.