Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NET6 - Wrong DateTime.ToString() formating when using monoVM and linux-arm #61598

Closed
michaldobrodenka opened this issue Nov 15, 2021 · 8 comments · Fixed by #62594
Closed

NET6 - Wrong DateTime.ToString() formating when using monoVM and linux-arm #61598

michaldobrodenka opened this issue Nov 15, 2021 · 8 comments · Fixed by #62594
Milestone

Comments

@michaldobrodenka
Copy link

michaldobrodenka commented Nov 15, 2021

Description

DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss.fff") - returns
2021-11-15 14:54:33.3378046 -when app is published with -p:UseMonoRuntime=true.
When using default runtime (without -p:UseMonoRuntime=true) it returns
2021-11-15 15:58:30.675

Reproduction Steps

I was testing minimum possible delay with following program:

using System.Diagnostics;

Stopwatch sw = new Stopwatch();

while(true)
{
    sw.Restart();
    Thread.Sleep(1);
    sw.Stop();
    Console.WriteLine($"{DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss.fff")} - Elapsed {sw.ElapsedMilliseconds}");
}

compiled with
dotnet publish -r linux-arm -p:PublishTrimmed=True -p:TrimMode=Link --self-contained true -c Release -f net6.0 -o bin\dotnet\mono -p:UseMonoRuntime=true for mono VM
and
dotnet publish -r linux-arm -p:PublishTrimmed=True -p:TrimMode=Link --self-contained true -c Release -f net6.0 -o bin\dotnet
for default runtime

Expected behavior

fff in DateTime.ToString() should return 1/1000ths of second

Actual behavior

fff in DateTime.ToString() return 1/10 000 000 of second

in screenshot - first with mono, then with dotnet default
image

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

Tested on 32bit linux-arm on Yocto linux

@dotnet-issue-labeler
Copy link

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged New issue has not been triaged by the area owner label Nov 15, 2021
@michaldobrodenka michaldobrodenka changed the title NET6 - Wrong millisecond time formating when using monoVM NET6 - Wrong DateTime.ToString() formating when using monoVM Nov 15, 2021
@lewing lewing added area-CoreLib-mono and removed untriaged New issue has not been triaged by the area owner labels Nov 15, 2021
@lewing lewing added this to the 6.0.x milestone Nov 15, 2021
@michaldobrodenka michaldobrodenka changed the title NET6 - Wrong DateTime.ToString() formating when using monoVM NET6 - Wrong DateTime.ToString() formating when using monoVM and linux-arm Nov 15, 2021
@Clockwork-Muse
Copy link
Contributor

.... the formatting code is unlikely to be in a runtime-dependent section. If you completely clean your build directories, does the issue persist?

@michaldobrodenka
Copy link
Author

Yes, I've retested it, deleted all the bin/obj and publish folders.

@michaldobrodenka
Copy link
Author

The same program running on Windows PC from VS and deployed to ARM mini PC:
image

@michaldobrodenka
Copy link
Author

Deleted bin, obj & publish folders, dotnet clean, then publish with default runtime, it's ok:
image

@michaldobrodenka
Copy link
Author

Deleted bin, obj & publish folders, dotnet clean, then publish with mono for win-x64, it's ok also:
image

@michaldobrodenka
Copy link
Author

so

  • windows x64 mono & dotnet ok
  • linux-arm - dotnet ok, mono - bug

@michaldobrodenka
Copy link
Author

monoVM linux-x64 tested on WSL - also ok

@simonrozsival simonrozsival self-assigned this Dec 2, 2021
@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Dec 2, 2021
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Dec 9, 2021
@simonrozsival simonrozsival removed their assignment Dec 9, 2021
directhex added a commit to directhex/runtime that referenced this issue Dec 9, 2021
So... there's no case where we don't want to assume hard float

Fixes: dotnet#61598
Fixes: dotnet#61599
@ghost ghost added the in-pr There is an active PR which will close this issue when it is merged label Dec 9, 2021
@ghost ghost removed the in-pr There is an active PR which will close this issue when it is merged label Jan 24, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Feb 24, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
4 participants