Time::HiRes: implement utime() for win32

[xenu]

We're in user-visible changes freeze, so this PR will probably have to wait until it's over.

[tonycoz]

Since Time::HiRes is dual-life, how well does this interact with the stat() from older CRTs with the DST bug used in older perls?

One reason I needed to implement win32_utime() as well as win32_stat() was to avoid the times in the result of stat() being an hour off a time set by utime().

[xenu]

I don't see how stat() DST bug affects utime(). If stat() returns the wrong timestamp, there's nothing utime() can do about it.

However, it seems that I completely forgot about leap seconds. Lifting your filetime_from_time() from win32.c should fix it. I'll mark this PR as a draft for now.

[xenu]

BTW, the other Time::HiRes functions also have this problem.

[jkeenan]

I don't see how stat() DST bug affects utime(). If stat() returns the wrong timestamp, there's nothing utime() can do about it.

However, it seems that I completely forgot about leap seconds. Lifting your filetime_from_time() from win32.c should fix it. I'll mark this PR as a draft for now.

@xenu, this p.r. has been in Draft status for more than a year. Do you still wish to pursue it?

[jkeenan]

I don't see how stat() DST bug affects utime(). If stat() returns the wrong timestamp, there's nothing utime() can do about it. However, it seems that I completely forgot about leap seconds. Lifting your filetime_from_time() from win32.c should fix it. I'll mark this PR as a draft for now.

@xenu, this p.r. has been in Draft status for more than a year. Do you still wish to pursue it?

@xenu, this p.r. is still in draft status -- and has acquired merge conflicts. Do you still wish to pursue it?

[demerphq]

HI @xenu, @jkeenan has asked twice about this PR, which is now very old. Do you intend to pick this up again or should we close it?

[demerphq]

@xenu I resolved the conflicts in this PR.