Linux Process.StartTime seems to use a different timebase than System.DataTime.Now and others

[stinos]

Description

The StartTime from a Process instance seems to use another timebase than the rest of the date/time-related functions, i.e. DateTime.Now. Tried on different machines and the StartTime seems to be too early, ranging from a couple to more than 100mSec depending on platform.

Reproduction Steps

First encountered this in Powershell on WSL, but it does the same when running on hardware.

Test script for Powershell:

$t1 = [System.DateTime]::Now
$pipeline = ({head -n 1}).GetSteppablePipeline($MyInvocation.CommandOrigin)
$pipeline.Begin($true)
Start-Sleep -Milliseconds 500
$t3 = (Get-Process head).StartTime
Write-Output "t1 = $($t1.Second).$($t1.MilliSecond), StartTime = $($t3.Second).$($t3.MilliSecond), $($process.StartTime -ge $t2)"
$pipeline.Process('foo')
$pipeline.End()

sample output on WSL 1 (Linux version 4.4.0-19041-Microsoft (Microsoft@Microsoft.com) (gcc version 5.4.0 (GCC) ) #1237-Microsoft Sat Sep 11 14:32:00 PST 2021) running with Powershell Core v7.2.1:

> pwsh ./CheckPsDateTime.ps1
t1 = 23.361, StartTime = 22.610, False
foo

Tried the same on actual hardware (Linux version 5.4.0-77-generic (buildd@lgw01-amd64-021) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #86~18.04.1-Ubuntu SMP Fri Jun 18 01:23:22 UTC 2021) but with dotnet sdk 6.0.101, installed from snap, with this code in Program.cs created by dotnet new:

var t1 = System.DateTime.Now;
var proc = System.Diagnostics.Process.Start("head");
var t2 = proc.StartTime;
Console.WriteLine($"{t1.Second}.{t1.Millisecond} vs {t2.Second}.{t2.Millisecond}");

sample output :

> /snap/dotnet-sdk/current/dotnet run
6.770 vs 7.760

Expected behavior

Process StartTime should use the same timebase as the other timing-related functions.

Actual behavior

Process StartTime returns values which are too small (or DateTime.Now returns values too large, hard to tell).

Regression?

No response

Known Workarounds

No response

Configuration

See Reproduction Steps above

Other information

No response

[ghost]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

The StartTime from a Process instance seems to use another timebase than the rest of the date/time-related functions, i.e. DateTime.Now. Tried on different machines and the StartTime seems to be too early, ranging from a couple to more than 100mSec depending on platform.

Reproduction Steps

First encountered this in Powershell on WSL, but it does the same when running on hardware.

Test script for Powershell:

$t1 = [System.DateTime]::Now
$pipeline = ({head -n 1}).GetSteppablePipeline($MyInvocation.CommandOrigin)
$pipeline.Begin($true)
Start-Sleep -Milliseconds 500
$t3 = (Get-Process head).StartTime
Write-Output "t1 = $($t1.Second).$($t1.MilliSecond), StartTime = $($t3.Second).$($t3.MilliSecond), $($process.StartTime -ge $t2)"
$pipeline.Process('foo')
$pipeline.End()

sample output on WSL (Linux version 4.4.0-19041-Microsoft (Microsoft@Microsoft.com) (gcc version 5.4.0 (GCC) ) #1237-Microsoft Sat Sep 11 14:32:00 PST 2021) running with Powershell Core v7.2.1:

> pwsh ./CheckPsDateTime.ps1
t1 = 23.361, StartTime = 22.610, False
foo

Tried the same on actual hardware (Linux version 5.4.0-77-generic (buildd@lgw01-amd64-021) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #86~18.04.1-Ubuntu SMP Fri Jun 18 01:23:22 UTC 2021) but with dotnet sdk 6.0.101, installed from snap, with this code in Program.cs created by dotnet new:

var t1 = System.DateTime.Now;
var proc = System.Diagnostics.Process.Start("head");
var t2 = proc.StartTime;
Console.WriteLine($"{t1.Second}.{t1.Millisecond} vs {t2.Second}.{t2.Millisecond}");

sample output :

> /snap/dotnet-sdk/current/dotnet run
6.770 vs 7.760

Expected behavior

Process StartTime should use the same timebase as the other timing-related functions.

Actual behavior

Process StartTime returns values which are too small (or DateTime.Now returns values too large, hard to tell).

Regression?

No response

Known Workarounds

No response

Configuration

See Reproduction Steps above

Other information

No response

Author:	stinos
Assignees:	-
Labels:	area-System.Diagnostics.Process, untriaged
Milestone:	-