Milliseconds to date and time

[jcampbell]

I have found a few threads on this and even found a little snippet of code that I thought may work for me but I am having trouble with it so I figured I would ask and see if this is possible.

I am getting a millisecond datetime stamp returned from some queries I am making via REST calls.  The returned date is something like this "1329414179000"

I tried the small function that PSaltyDS shared that is shown below and it gets me to what I need somewhat I just don't understand why my time is off.

When I parse the millisecond value I have, it is returning the time as PM in the format of  2012/02/16/ 17:42:59.  I know that the date is correct and the min:sec of the time is correct but I am getting the wrong hour.  The string should read 2012/02/16 11:42:59.  The file was created in the AM not the PM.  I don't mind it reporting in military time I just am not sure why its off by 7 hours.

I have also looked at the built in time function _ticks to time but from what I have not been able to get that work for it yet.

#Include <Date.au3>

$n = 1329414179000
ConsoleWrite("$n = " & $n & @LF)
$sTime = _DateAdd("s", Int($n / 1000), "1970/01/01 00:00:00")
ConsoleWrite("$sTime = " & $sTime & @LF)

 

[BrewManNH]

What's your time zone? And what is the difference between your time zone and UTC?

[JohnOne]

Add 7 hours to "1970/01/01 00:00:00"

[jcampbell]

I'm in the Central time zone.  So that's a 6 hour difference off of UTC.  When its 12:00pm central time that's 6:00pm UTC. 

So Taking that I changed the 00:00:00 to 18:00:00 and I get the correct time just a day later so instead of the 16th I indexed it to the 17th.

[jcampbell]

Ok so started tracking back and really should not have hit send on that last post yet.  I took the date back to say 1969/12/31 18:00 and then I get the correct date and time for my return.  my question is this simply an issue with time zone conversions? Is my source I am getting the millisecond return from using something other than the computer epoch to count from?  Is that not what 1970/01/01 00:00:00 adding to?

Thanks,  just trying to understand what is going on here.  Don't really want someone to write me something I want to know what is happening.

[BrewManNH]

The epoch time is based on UTC, so unless you live in that time zone, all times will be off at least by your time zone difference.

[jcampbell]

Ok,  So that I can understand based on the fact that I am 6 hours difference from UTC and I really should have thought about that before posting but why the day?   

O well got it figured out and that is what counts.  Its more one of those things that will bother me.  Thanks for the help guys.

[BrewManNH]

Well, what is 6 hours before midnight January 1st, 1970? Answer, December 31st, 1969 @ 1800 hours.

[JohnOne]

I've been thinking about this, and after a search about it's raised a few questions.

 

What is the difference between system time and local time?

 

A few topics I found where people where looking to get system time, they were advised to use _NowCalc(), but I'm fairly certain that returns local time.

 

According to msdn GetSystemTime "is expressed in Coordinated Universal Time (UTC)"

 

So what is the difference?

 

I don't believe I can test it in UK because both of these return the same time (GMT/UTC)

 

I'm hoping one shows UTC and the other shows UTC +- local offset, and wonder if someone in different timezone would be so kind as to test it.

 

$SYSTEMTIME = DllStructCreate( _
        "WORD wYear;" & _
        "WORD wMonth;" & _
        "WORD wDayOfWeek;" & _
        "WORD wDay;" & _
        "WORD wHour;" & _
        "WORD wMinute;" & _
        "WORD wSecond;" & _
        "WORD wMilliseconds;")

$pSYSTEMTIME = DllStructGetPtr($SYSTEMTIME)

$aCall = DllCall("Kernel32.dll", "none", "GetSystemTime", "ptr", $pSYSTEMTIME)
;$aCall = DllCall("Kernel32.dll", "none", "GetLocalTime", "ptr", $pSYSTEMTIME)

If @error Then
    Exit MsgBox(0, 0, 0)
EndIf

ConsoleWrite( _
        DllStructGetData($SYSTEMTIME, 1) & "-" & _
        DllStructGetData($SYSTEMTIME, 2) & "-" & _
        DllStructGetData($SYSTEMTIME, 4) & "-" & _
        DllStructGetData($SYSTEMTIME, 5) & "-" & _
        DllStructGetData($SYSTEMTIME, 6) & "-" & _
        DllStructGetData($SYSTEMTIME, 7) & "-" & _
        DllStructGetData($SYSTEMTIME, 8) & @LF)

[jdelaney]

Don't forget about days light savings time! (not now, but in 5 months)

Looks like my system time is displaying the UTC/GMT 2013/12/5-20:14:7.58

I'm in California, which currently is a -8 hour offset (12:14 in 24 hour clock)...durring days light savings time: -7

$aCall = DllCall("Kernel32.dll", "none", "GetLocalTime", "ptr", $pSYSTEMTIME)

This one does not return the offset, it must be inferred by the difference, I suppose

2013/12/5-12:18:0.111

Edited December 5, 2013 by jdelaney

[JohnOne]

Are both GetSystemTime and GetLocalTime displaying the same?

[BrewManNH]

I'm in the Eastern Time Zone (UTC -5) and GetSystemTime shows 20:18, GetLocalTime shows 15:18 for me.

Windows 7

[jdelaney]

Just updated my first post.  GetLocalTime is the system clock time, and GetSystemTime is utc

Edited December 5, 2013 by jdelaney

[JohnOne]

What I expected then (for a change)

Does anyone know of an existing UDF for this?

[jdelaney]

#include <Date.au3>

_Date_Time_GetLocalTime
_Date_Time_GetSystemTime

#include <date.au3>
$t = _Date_Time_GetLocalTime()
ConsoleWrite(  _Date_Time_SystemTimeToDateTimeStr($t) & @CRLF)
$t = _Date_Time_GetSystemTime()
ConsoleWrite(  _Date_Time_SystemTimeToDateTimeStr($t) & @CRLF)

Edited December 5, 2013 by jdelaney

[JohnOne]

Oh well, it passed some time, I did look, just not well enough it appears.

Cheers gentlemen.