Announcement

Collapse
No announcement yet.

Bug in Windows?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Scott Turchin
    replied
    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>

    Leave a comment:


  • Eric Pearson
    replied
    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).]

    Leave a comment:


  • Scott Turchin
    started a topic Bug in Windows?

    Bug in Windows?

    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!!

    Code:
    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>
Working...
X