B4J Question Parsing times that may be wrong

[Chris2]

I'm receiving a time HH:mm:ss from some hardware.
When received, I'm parsing it with:

DateTime.TimeFormat = "HH:mm:ss"
Dim longTime As Long = DateTime.TimeParse(strTime) 'strTime comes from the hardware

Then using longTime for various other operations.

The DateTime.TimeParse hint states 'Note that the returned value date will be today'.
The problem is that strTime may not be exactly correct, and around midnight the day it relates to might be different from the current date on the PC.

I'm getting around this by doing:

DateTime.TimeFormat = "HH:mm:ss"
    Dim longTime As Long = DateTime.TimeParse(strTime) 'strTime comes from the hardware
    
    Dim pcHour As Long = DateTime.GetHour(DateTime.Now)
    Dim hwHour As Long = DateTime.GetHour(longTime)
    If pcHour=23 And hwHour=0 Then 'hw clock is ahead of PC so add a day to longTime
        Dim p As Period
        p.Initialize
        p.Days=1 
        longTime=DateUtils.AddPeriod(longTime, p)
    Else If pcHour=0 And hwHour=23 Then 'hw clock is behind PC so subtract a day from longTime
        Dim p As Period
        p.Initialize
        p.Days=-1 
        longTime=DateUtils.AddPeriod(longTime, p)
    Else
        longTime=longTime
    End If

This obviously won't work if the hardware time and PC time are more than an hour different (although this is pretty unlikely in the real world).
Is there a better way to handle this?

Many thanks.

 

[agraham]

Why do you need to relate the hardware date with the PC date? For example, wearing one of my former hats, if hardware were an industrial monitor/controller I would probably design the system such that its time would be the reference and all data collection and control would be referenced to the hardware time.

 

[Chris2]

The hardware doesn't hold/send the date, only the time in HH:mm:ss format.

I'm using the hardware time as the reference everywhere as you suggest, but I need to get the date that the hardware time relates to from somewhere.

 

[agraham]

An alternative might be to maintain a date for the hardware independent of the PC. Synchronise that date on start up and increment the hardware date whenever the current hardware time is less than the previous hardware time.

 

[udg]

Hi, I'm not sure this can work; it's just an idea where I do consider the time gap between the clocks.

dim threshold as long = 22  ' two hours gap between PC and hardaware
    DateTime.TimeFormat = "HH:mm:ss"
    Dim longTime As Long = DateTime.TimeParse(strTime) 'strTime comes from the hardware
    
    Dim pcHour As Long = DateTime.GetHour(DateTime.Now)
    Dim hwHour As Long = DateTime.GetHour(longTime)
    If pcHour=23 And (pcHour-hwHour>= threshold) Then 'hw clock is ahead of PC so add a day to longTime
        Dim p As Period
        p.Initialize
        p.Days=1 
        longTime=DateUtils.AddPeriod(longTime, p)
    Else If pcHour=0 And (hwHour-pcHour>=threshold) Then 'hw clock is behind PC so subtract a day from longTime
        Dim p As Period
        p.Initialize
        p.Days=-1 
        longTime=DateUtils.AddPeriod(longTime, p)
    End If

 

[MicroDrie]

I receive a time HH:mm:ss from some hardware.

You are asking for a solution with a very vaguely defined environment. The first ambiguity is whether and if so how some hardware devices will ever be set on time. Because if the difference in leading and trailing is more than 23:59:59 (hh:mm:ss), the date can no longer be added at all.
When I started programming in the second half of the seventies, PC times started to lag because the clock interrupts were briefly turned off. After a long time you really had to set the clock to the right time.

Then there's the point of "Why make it hard when it can do a lot harder?". Today, your PC is synchronized with a central clock. Why is that? Simple because it is then possible to reconstruct what happened in what order on the basis of the times. You really need this time reference source for that reconstruction. That raises the question of why you want to save the wrong time? The only acceptable answer to that is: The time on some hardware is synchronized with the reference time with no date, but between setting the time and sending that time there can be arise a few seconds, minutes, or hours delay. If that's the answer, some hardware's timekeeping may just be lagging! and yes, if a maximum delay time should be known.

Back again to "do it a lot harder", why don't you just log the real time as a date and time entry with the time message from some hardware when you got it?

 

[Chris2]

@agraham - thanks for that. Maintaining a date for the hardware in the app is definitely another approach, that I hadn't thought of.
@udg - Thanks also. I'm not sure your code would work too differently to the original, there's still a cut-off point where it won't work (the chosen threshold). But using the time difference might is another approach that I hadn't thought of that.
I need to think both of these options through, and maybe use a combination of them & the original code.

@MicroDrie - thanks for your response as well. Apologies, my initial post was a little vague I guess.

why don't you just log the real time as a date and time entry with the time message from some hardware when you got it?

The hardware is a data logger that stores data/events into time periods (hourly for example). I need to use the time reported by the hardware so that I know what period it is in in relation to its own time.

The only acceptable answer to that is: The time on some hardware is synchronized with the reference time with no date, but between setting the time and sending that time there can be arise a few seconds, minutes, or hours delay.

Yes, the hardware time is synchronised once a day, so it shouldn't drift too far before the next synchronisation. Hence the code in post 1 should be enough 99.9% of the time. I'm just trying to cover all bases here and (perhaps stupidly) cope with the 0.1% of occasions when it drifts more than 1 hour.

"Why make it hard when it can do a lot harder?"

I'm not sure what you mean by this?

 

[MicroDrie]

"Why make it hard when it can do a lot harder?"

I'm not sure what you mean by this?

The best solution is based on good principles that give a useful result for the intended purpose. Then the first question is:

What is the undeniable goal of opting for or omitting a specific solution for that particular problem?

After all your additions, I now understand that it is a log overview of events that occurred in a certain time period (an hour for example) on a device a shift away time difference.

After all your additions, I now understand that it is a log overview of events that occurred in a certain time period (an hour for example) on a device a shift away time difference. If registration alone is sufficient, you can suffice with only recording what time you received the received events.

It becomes much more difficult if the condition is that the logging must take place in a manner within which a recorded time difference must be resolved when each recorded event has occurred. If this is not a requirement, then you should not make the effort, if it is a hard requirement, then more is needed to meet the hard requirement. Or it is impossible to realize a solution and then it makes no sense to put a lot of effort into it and the commitment is sufficient to receive it this time.

I would like to look for a solution in more detail with you in a private e-mail.