SysTime- Library

[mjcoon]

Originally Posted by agraham

I suspect they contain the DST information for the time zone.

Ah, yes, I'm sure you are right, and I can see "GMT" and "British Summer Time" there (and show with a jolly useful Converter.Utf16FromBytes() call!).

But I gather from skimming M$ web stuff that there should be a bias value in minutes in there somewhere, amounting to 60 minutes of daylight saving at the moment, but I can't find it...

Isn't this standard locale information that should be readily available?

Mike.

[agraham]

Originally Posted by mjcoon

Isn't this standard locale information that should be readily available?

If you mean visible to the user then I don't think so, at least in Windows. I think the DST has always been either manual,as in the old days , or automatic and invisible to the user in more modern times.

[mjcoon]

Originally Posted by agraham

If you mean visible to the user then I don't think so, at least in Windows. I think the DST has always been either manual,as in the old days , or automatic and invisible to the user in more modern times.

I've long thought that given the USA has several time zones and daylight saving, Windows time handling is rather clumsy. (I believe that when the clocks change, you'll see the times you wrote yesterday's files also appear to change by one hour!)

But if I click on the time in the system tray, the calendar that appears shows "Current time zone: GMT Daylight Time".

I've found the "Active Time Bias" in the registry bytes, at the end. Equals -60 right now. Retrieved by:

Converter.Int32FromBytes(zti(), 168)

Mike

[mjcoon]

Originally Posted by alfcen

Sorry gents,
There is an error in
mnuSetSystemDateTime_Click
which I have corrected as:

Sub mnuSetSystemDateTime_Click
  If GPS.Status="A" Then
    Dim x, i
    x =DateParse(GPS2Time(GPS.UTCTime))   'addition of time zone must account for date change
    x = x - x Mod cTicksPerDay 
    x = x + TimeParse(GPS2Time(GPS.UTCTime)) + zt * cTicksPerHour
...
End Sub

I have finally worked out what alfcen meant by the 'addition of time zone must account for date change' comment. It's because the TimeParse() function rather strangely adds the time increment to the current date to generate the full ticks value.

But this complication can be avoided completely by using the convenient TmeAdd() function. Thus the date is parsed first, as above, then the time added to it.

The same function can be used again to add the local offset (which Microsoft likes to keep as the increment to go from local time to UTC) directly in minutes, so no division by 60 is needed either.

Using ByteConverter DLL (which it happens that my code already was) rather than BitWise DLL, makes the code for deriving the local offset much simpler too.

Mike.

[agraham]

Originally Posted by mjcoon

It's because the TimeParse() function rather strangely adds the time increment to the current date to generate the full ticks value

Yes, it's an annoying quirk of the .NET DateTime Parse method that it adds the current date to the time when it parses a string if there is no date specified. I have no idea why someone thought that behaviour was a good idea .

[Filippo]

Hallo agraham,

@Filippo - how about hiding "SYSTEMTIME" by renaming it "_SYSTEMTIME"

I added the change.

and providing the sources for merging?

I can not, I know myself not using c#

Ciao,
Filippo

[mjcoon]

By way of restitution for my criticism of alfcen's code (which he invited us to shorten) and pay-back for all the assistance here, I offer my version of the crucial portion.

It assumes the presence of a multi-line textBox1 for display of disparate times, which is of course optional. Only if the time disparity is greater than one second does it invite the user to confirm alteration of system time. The user can prevaricate as long as desired without impacting the accuracy!

It uses ByteConverter DLL rather than BitWise DLL, which makes the code for deriving the local offset much simpler.

The original system time is a parameter so that it can be measured at the time that the GPS time is acquired, so that the time taken to perform parsing is not added in.

I don't know why the local time offset appears at registry value byte 168 in my PDA versus byte zero in alfcen's.

'Requires Registry DLL (object reg), ByteConverter DLL and Filippo's SysTime DLL (object SysTime)

Sub CompareSystemTime(nowTicks, yearUTC, monthUTC, dayUTC, hourUTC, minuteUTC, secondUTC)
    moString = Format(monthUTC, "D2")
    dyString = Format(dayUTC, "D2")
    yrString = Format(yearUTC, "D4")
    DateFormat("yyyy-mm-dd")
    TimeFormat("HH:mm:ss")
    dateString = yrString & "-" & moString & "-" & dyString
    dateTicks = DateParse(dateString)
    timeUTCTicks = TimeAdd(dateTicks, hourUTC, minuteUTC, secondUTC)
    textBox1.Text = "Date&time (UTC)=" & CRLF & cTab & Date(timeUTCTicks) & "  " & Time(timeUTCTicks)
    minsOffset = - GetActiveTimeBias
    timeTicks = TimeAdd(timeUTCTicks, 0, minsOffset, 0)
    disparity = Int((timeTicks - nowTicks) / cTicksPerSecond + 0.5)
    If disparity = 1 Then
        unit = " second"
    Else
        unit = " seconds"
    End If
    textBox1.Text = textBox1.Text & CRLF & "Date&time (local)=" & CRLF & cTab & Date(timeTicks) & "  " & Time(timeTicks) & _
            CRLF & "System time =" & CRLF & cTab & Date(nowTicks) & "  " & Time(nowTicks) & _
            CRLF & "Time disparity = " & disparity & unit
    If Abs(disparity) > 1 Then
        If Msgbox("Disparity = " &     disparity & unit, "Adjust system time?", cMsgboxYesNo) = cYes Then
            adjustTime(disparity)
        End If
    End If
End Sub

Sub GetActiveTimeBias        'In minutes, to go from local to UTC (!)
  Dim m, i, b
  Reg.New1
  Reg.RootKey(Reg.rtLocalMachine)
  If cPPC = True Then
    zti()=Reg.GetValue("Time","TimeZoneInformation")
    m = Converter.Int32FromBytes(zti(), 168)
  Else
    m = Reg.GetValue("System\CurrentControlSet\Control\TimeZoneInformation","ActiveTimeBias")
  End If
  Return m    
End Sub

Sub adjustTime(seconds)
    TimeObj.New1
    timeNow = Now
    timeAdjusted = timeNow + seconds * cTicksPerSecond
    TimeObj.SetDate(DateMonth(timeAdjusted),DateDay(timeAdjusted),DateYear(timeAdjusted))    ' Tweak the current system date
    TimeObj.SetTime(TimeHour(timeAdjusted),TimeMinute(timeAdjusted),TimeSecond(timeAdjusted))     ' Tweak the current System time
End Sub

[mjcoon]

Originally Posted by mjcoon

By way of restitution for my criticism of alfcen's code (which he invited us to shorten) and pay-back for all the assistance here, I offer my version of the crucial portion. ...

Back then, I complained that alfcen's code did not appear to allow for daylight saving (because at least in my registry it was not included in the data that he extracted).

I offered my own alternative, which seemed to work in zulu time zone and with daylight saving.

But now I try to re-visit the code I find that my registry content still thinks that we are in British Summer Time and daylight saving.

Has anyone in the interim found a reliable way of determining the offset between UTC and local time?

Mike.

[agraham]

Is this what you want. Obj1 is a Door library Object, Args1 is a Door library ObjectArray.

    Obj1.New1(False)
Args1.New1(1)
Args1.SetValue(0, 0, "System.Int64")
Obj1.CreateNew2("System.DateTime", Args1.Value)
Obj1.Value = Obj1.GetProperty("UtcNow")
UtcTicks = Obj1.GetProperty("Ticks")
LocalOffset = Now - UtcTicks

[nl1007]

Originally Posted by Zenerdiode

Hi Filippo,

I think there is an error in your help file for SetDate

Its looking as if the Day and Month are swapped i.e. it should read:
Syntax: SetDate(Month As Integer, Day As Integer, Year As Integer)

I didn't notice a confirmation of this, but swapping them over does set the date..
Does anybody know why the US date format is so illogical? It causes so many problems.. (and partial implementation / use of 'regional settings', even within the same [MS] Application, just makes it worse)