Bug in Windows?

[Scott Turchin]

I've been kicking this dead horse and I can't seem to see why nobody else sees this issue in their applications.

But, the StrToVBDate function that's been posted here quite a bit is apparantly not working.

I fed it THIS NIST time (as logged when retrieved):
(Been testing as you can see)

51930 01-01-21 15:39:16 00 0 0 584.8 UTC(NIST) *
51930 01-01-21 15:46:06 00 0 0 978.7 UTC(NIST) *
51930 01-01-21 15:46:16 00 0 0 102.5 UTC(NIST) *
51930 01-01-21 15:46:19 00 0 0 454.8 UTC(NIST) *

Now, notice the year!!! Notice where it's at? This does not seem right...
One would EXPECT it on the right hand side:
01-21-01 but Windows does soemthing weird with thsi, so my remedy is below and it NOW WORKS!!

Function StrToVbDate(ByVal dt As String) Export As Double
  Local x      As Long
  Local y      As String
  Local vbdate As Double
  Local lResult As Long
  Local stDay   As String
  Local styear  As String


'  01-01-21
  stday = Mid$(dt,4,2)
  stYear = Mid$(dt,7,2)
'Swap the day and the year from NIST time: Problem solved here
  Mid$(dt,7,2) = stday
  Mid$(dt,4,2) = styear

  dt = uString(dt)
'  If IsFalse(VarDateFromStr(ByVal StrPtr(dt), %LOCALE_USER_DEFAULT, %LOCALE_NOUSEROVERRIDE, vbdate)) Then
  lResult = VarDateFromStr(ByVal StrPtr(dt),0, 0, vbdate)
  Select Case lResult
        Case %FALSE
           Function = vbdate
        Case %DISP_E_TYPEMISMATCH 'Can't convert string to date, set 0 and invalidate
           Function = %FALSE
        Case %DISP_E_OVERFLOW
           Function = -1
        Case %E_OUTOFMEMORY      'Throw exception here
           Function = %FALSE
  End Select
End Function

------------------
Scott
mailto:[email protected][email protected]</A>

[Eric Pearson]

Scott --

> 51930 01-01-21

> Now, notice the year!!!

> One would EXPECT it on the right hand side

I wrote an NIST clock-sync program about 10 years ago, and I'm 99.44% sure that the NIST has always transmitted the date in the YY-MM-DD "descending" format. I looked at my old code, and it uses the Julian date at the beginning of the string instead of the YY-MM-DD date, so I can't be sure. I suppose it's possible they changed the string format on 1/1/2001 but I think that's pretty unlikely. They would break many, many programs if they did that. (Not mine, however. )

MM-DD-YY is the U.S. standard, but outside the U.S. DD-MM-YY is far more common. YY-MM-DD is unambiguous. Until recently when you looked at a date like 99-01-02 it was pretty clear that the year was first, thereby making it clear that the format was YY-MM-DD. Now that the centuty has changed it will be a few years until you can look at a YY-MM-DD and be sure what it is, but it is the truly "international" date format and I run into it quite often.

I'm curious... WHy do you think this is a Windows bug? It seems to me that the APIs are working as expected, it's just that you are supplying data in the wrong format. Am I missing something?

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited January 21, 2001).]

[Scott Turchin]

Just seems weird that this same piece of code worked for 2 years now....

My suspicions are that Windows (and I read thsi somewhere) interprets that string, parses it out and uses it...

But now that is has two "01"'s in it and the date on the right hand side my suspicion is that it's Windows parsing it wrong.

I haven't changed the code in two years, same 3 functions have been used to check the clock since I first wrote that program...albeit the program has never been DONE but it has the functionality already..

So it's Windows interpreting that string "01-01-21 15:36:00 blah blah" in the VarDateFromStr api call, and it's pretty ambiguous but Windows does the best it can..

I can't see any other explanation, this has always worked.
And maybe it's just that I'm the only one using the string instead of the julian date..


Do you have a sample of how to convert a julian date to a SYSTEMTIME STRUCTURE????


Might be a good time to change....


Scott

------------------
Scott
mailto:[email protected][email protected]</A>