Problems with getting date and time from timestamp

[markster]

I'm trying to get the date and time from a timestamp that has an offset from UTC time. To get the date, I'm using the following:

  LOC:Seconds = pTimeStamp/1000
  LOC:Days = INT(LOC:Seconds/(24 * 60 * 60))
  LOC:Date = LOC:Days + UTCBaseDate !61730 base date

This normally works, but if I'm in PDT time, which is 7 hours behind UTC, and I generate a TimeStamp using p_web.GetElapsedTimeUTC() after 5pm PDT time (ie after 12midnight UTC), and then try to pull the date from that TimeStamp, I end up getting the date of PDT time whereas it should be the date of UTC time (ie tomorrow). Is there some formula that someone has to do this correctly?

Thanks,

Mark

[Bruce]

Hi Mark,

I think what you are asking is;
a) Given a UTC time Stamp as returned by p_web.GetElapsedTimeUTC()
b) is there a way to convert this to Clarion Date / Time
?

The answer is yes, at least if you are doing web server stuff.

utc =  p_web.GetElapsedTimeUTC() / 1000
d = p_web.UnixToClarionDate(utc)
t = p_web.UnixToClarionTime(utc)

Cheers
Bruce

updated: GetElapsedTime returns a REAL, with time in milliseconds. UnitTo... takes a Long with the number in seconds. - thanks Mark.

[markster]

Bruce, I'm still getting inaccurate numbers with your code. First, p_web adds milliseconds in the GetElapsedTimeUTC function, so the utc variable needs to be divided by 1000 before using the Unix functions. That aside, the problem I'm having with your p_web formula is that it is not accurately calculating the date at certain times of the day. I fiddled with this at 11pm PDT on 4/14/16, ie, 7 hours behind UTC. I used your code as follows:

utc = p_web.GetElapsedTimeUTC()/1000
d = p_web.UnixToClarionDate(utc) 
t = p_web.UnixToClarionTime(utc)

This resulted in a date of 4/14/16 and a time of 6:00am. But that date should be calculated as 4/15/16 because utc is 7 hours ahead of my local time.

When I used the same code after midnight, ie at 12:01am PDT with the local date now being 4/15/16, I got the correct date and time result from the above code.

Thanks,

Mark

[Bruce]

hi Mark,

thanks for the update - I've updated by answer so it is correct now.

Regarding the time - I suppose the obvious thing to ask up front - are you sure your machine is set in the "right" time zone? If the time was just "set right" but it thought it was in another time zone then you're gonna get weird results like this. I _think_ from your notes that it _is_ ok, but check it jsut to be sure...

>> I fiddled with this at 11pm PDT on 4/14/16, ie, 7 hours behind UTC.

what as the value of UTC (ie the actual number) at this time please?
(I don't need the value _then_ but if you could give me the value at 11pm on any day that would be useful. Thanks.)


cheers
Bruce

[markster]

Bruce, enclosed are 2 jpg's showing the date and time calcs, one at 4:12pm PDT and one at 5:03pm PDT. The second has the errors as the 7 hour time difference from UTC puts the UTC time into the next day, but the calculated UTC date is incorrect. Here's the code that shows the calcs and variables displayed in the jpg's. Just look at the UTC variables. I started to fiddle with compensating for the error, but haven't thought it all through yet. Thanks,Mark

  LOC:UTCTimeStamp = pTimeStamp/1000 ! convert to long, no milliseconds
  LOC:UTCDate = p_web.UnixToClarionDate(LOC:UTCTimeStamp)
  LOC:UTCTime = p_web.UnixToClarionTime(LOC:UTCTimeStamp)

  LOC:UTCDateString = Format(LOC:UTCDate,@d2)
  LOC:UTCTimeString = Format(LOC:UTCTime,@t3)

  LOC:Date = LOC:UTCDate

  !! adjust to local time zone (PDT for now)
  LOC:TimeZoneAdjustment = -7
  LOC:Time = LOC:UTCTime + (LOC:TimeZoneAdjustment * 100*60*60)

  IF LOC:Time < 0
    LOC:Date -= 1
    LOC:Time = LOC:UTCTime + ((24 - ABS(LOC:TimeZoneAdjustment) * 100*60*60))
  ELSIF LOC:Time > (100*60*60*24)
    LOC:Date += 1
    LOC:Time -= (100*60*60*24)
  END

  ! testing display
  LOC:DateString = Format(LOC:Date,@d2)
  LOC:TimeString = Format(LOC:Time,@t3)

[markster]

Bruce, are you working on a fix for this?

Thanks,

Mark

[Bruce]

Hi Mark,

oh, sorry, no I wasn't working on this.
what I was waiting for was the value of UTC. ie, given the code;

utc = p_web.GetElapsedTimeUTC()/1000

what as the value of UTC (ie the actual number) at this time please?
(if you could give me the value "late" on any day that would be useful. Thanks.)

If you can let me have that value then I can take it from there.

cheers
Bruce

[markster]

If you look at the 2nd jpg I posted up above, you'll see the utc calculations generated/made at 5:02pm PDT (ie 0:02am UTC). The LOC:UTCTIMESTAMP variable shown is the reading that you want. If you look at the sample code I posted along with the pjg's you'll see how all of the LOC:UTC... variables in the jpg came to be (as I mentioned before, ignore the local variables that are not LOC:UTC... because I had just started fiddling with work arounds).

Mark

[markster]

Bruce, I'm still trying to get to the bottom of the UTC date issue. Here's the data. I'm in Pacific Daylight Time, 7 hours later than UTC base time:

Reading #1 4/19/16 4:12pm PDT  UTCTimeStamp from NetWebServer.GetElapsedTimeUTC() = 1461107575  UTCDate from NetWebServer.UnixToClarionDate = 78640
Reading #2 4/19/16 5:02pm PDT  UTCTimeStamp from NetWebServer.GetElapsedTimeUTC() = 1461024154  UTCDate from NetWebServer.UnixToClarionDate = 78640

The obvious problem is that Reading #2 should have a UTC timestamp greater than Reading #1. It's generating the correct UTC time, but not the date, which should be UTC 4/20/16 12:02AM, ie the UTCDate should be 78641.

Since the NetTalk GetElapsedTimeUTC() function is reading the local computer's date/time stamp and then calculating the UTC, the function must have additional code that compensates for time zone gaps. As it stands right now with my case of PDT being 7 hours behind UTC, the UTC times generated by the NetTalk function from 5pm to midnight will always have an incorrect UTC date.

Regards,
Mark

[Bruce]

Hi Mark,

>> Since the NetTalk GetElapsedTimeUTC() function is reading the local computer's date/time stamp and then calculating the UTC, the function must have additional code that compensates for time zone gaps.

no, it gets the UTC time from the computer itself. It uses the windows GetSystemTime API to do this. (the API is prototyped in netmap.inc, and that is documented here;
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724390(v=vs.85).aspx

However the function also uses Clarion's TODAY function - which of course returns _local_ Date, and hence the problem.
I've tweaked for the next build of course, but you can fix there as well if you like. The method is in NetAll.Clw.

The code for the method should now read;

!------------------------------------------------------------------------------
! Returns a REAL containing the milliseconds elapsed since 1 January 1970 00:00:00 UTC up until now
_NetAll.GetElapsedTimeUTC     Procedure (Long pBaseDate=61730)   ! 61730 = 1 jan 1970
msPerDay            real(24 * 60 * 60 * 1000)    ! don't make this an equate, needs to force the calc below to be real.
msPerHour           equate     (60 * 60 * 1000)
msPerMinute         equate          (60 * 1000)
msPerSecond         equate               (1000)
today               long
ans                 Real
tim                 Group(NET_SYSTEMTIME).

  code
  OS_GetSystemTime(tim)   ! returned time is for UTC not local time
  today = date(tim.wMonth,tim.wDay,tim.wYear)
  ans = (( today - pBaseDate ) * msPerDay ) + (tim.wHour * msPerHour) + (tim.wMinute * msPerMinute) + (tim.wSecond * msPerSecond) + tim.wMilliseconds
  return ans

Note the change of the use of today() to the calculated variable.

Thanks for persisting with this.

cheers
Bruce

[markster]

Whooo hooo! Thanks.