Recent

Author Topic: Issue with DateUtils.ScanDateTime and milliseconds  (Read 1213 times)

winni

  • Hero Member
  • *****
  • Posts: 2323
Re: Issue with DateUtils.ScanDateTime and milliseconds
« Reply #15 on: April 09, 2021, 10:26:54 pm »
@wp, @alpinistbg: I don't think you're disagreeing with each other.

I think we have a consensus that 22.8 *should* be interpreted as 22.800 not 22.008

MarkMLl

And everybody who disagrees should go back to school.

Shaking the head.

Winni

MarkMLl

  • Hero Member
  • *****
  • Posts: 2486
Re: Issue with DateUtils.ScanDateTime and milliseconds
« Reply #16 on: April 09, 2021, 10:37:00 pm »
And everybody who disagrees should go back to school.

Subject obviously to the dismal delimiter.

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

BeniBela

  • Hero Member
  • *****
  • Posts: 788
    • homepage
Re: Issue with DateUtils.ScanDateTime and milliseconds
« Reply #17 on: April 10, 2021, 02:16:05 pm »
Hence I  wrote my own [date time functions](https://github.com/benibela/bbutils/blob/master/bbutils.pas#L761-L819):

Code: [Select]
timeParse('00:00:22.8', 'hh:nn:ss.z+')
800ms as it should be

y.ivanov

  • Jr. Member
  • **
  • Posts: 96
Re: Issue with DateUtils.ScanDateTime and milliseconds
« Reply #18 on: April 10, 2021, 08:45:47 pm »

ASBzone

  • Hero Member
  • *****
  • Posts: 615
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: Issue with DateUtils.ScanDateTime and milliseconds
« Reply #19 on: April 12, 2021, 04:56:42 am »
and that is correct.
I don't know about other OSes but in windows the MS is a value not a fraction and its not 0..59 of course

simply use some string functions to trim the right side and use that value give you a fraction if that is what you want.

It's a fraction in Windows as well, but with the thousandths place empty.  The resolution is to 10 ms, not 1 ms.

I tested this quite a bit back in 2019 (or so), and by comparing various tools, I was able to see that 1:29.24 as returned by Windows, was really 1:29.24x (as in, .240 - .249, and not .024)

@y.ivanov,
you will need to make the adjustment yourself.   The values that are returned in FPC are actually 0-999 for the ms.   If you are comparing those values to numbers grabbed from logs or some other tool, or found in other OSes (especially Windows), you may have to make post-processing adjustments.
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.0.13 r64843 / FPC v3.2.1-r49055 (via FpcUpDeluxe) -- Windows 64-bit install w/Win32 and Linux/Arm cross-compiles
Primary System: Windows 10 Pro x64, Version 2009 (Build 19042)
Other Systems: Windows 10 Pro x64, Version 2009 (Build 19042) or greater

ASBzone

  • Hero Member
  • *****
  • Posts: 615
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: Issue with DateUtils.ScanDateTime and milliseconds
« Reply #20 on: April 12, 2021, 04:58:53 am »
@wp, @alpinistbg: I don't think you're disagreeing with each other.

I think we have a consensus that 22.8 *should* be interpreted as 22.800 not 22.008

MarkMLl

Precisely.
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.0.13 r64843 / FPC v3.2.1-r49055 (via FpcUpDeluxe) -- Windows 64-bit install w/Win32 and Linux/Arm cross-compiles
Primary System: Windows 10 Pro x64, Version 2009 (Build 19042)
Other Systems: Windows 10 Pro x64, Version 2009 (Build 19042) or greater

 

TinyPortal © 2005-2018