Date to Unix Timestamp conversion

[KaFu]

Was searching the forum and the help-files in vain... until I stumbled across the expression "since EPOCH" in the _DateDiff() example ... vice versa conversion shouldn't be a problem.

#include <Date.au3>

; Ref http://de.wikipedia.org/wiki/Unixzeit#Besondere_Werte

; Now
$iDateCalc = _DateDiff( 's',"1970/01/01 00:00:00",_NowCalc())
MsgBox( 4096, "", "Number of seconds since EPOCH: " & $iDateCalc )

; Ref from Wikipedia #1 => 1000000000
$iDateCalc = _DateDiff( 's',"1970/01/01 00:00:00","2001/09/09 01:46:40")
MsgBox( 4096, "", "Number of seconds since EPOCH: " & $iDateCalc )

; Ref from Wikipedia #2 => 1234567890
$iDateCalc = _DateDiff( 's',"1970/01/01 00:00:00","2009/02/13 23:31:30")
MsgBox( 4096, "", "Number of seconds since EPOCH: " & $iDateCalc )

; Ref from Wikipedia #3 => 2000000000
$iDateCalc = _DateDiff( 's',"1970/01/01 00:00:00","2033/05/18 03:33:20")
MsgBox( 4096, "", "Number of seconds since EPOCH: " & $iDateCalc )

Best Regards

[Mat]

Simple 1 line to get current timestamp. Appareo Decet Nihil Munditia?

MsgBox (0, "Current date:", ((@YEAR - 1970) * 31557600) + (int ((@YEAR - 1972) / 4) * 86400) + ((@YDAY - 1) * 86400) + (@HOUR * 3600) + (@MIN * 60) + @SEC)

Reverse method, not using any includes, but some ideas taken from date.au3, such as how to get the leapyear.

MsgBox (0, "1234567890", _GetDateFromUnix (1234567890))

Func _GetDateFromUnix ($nPosix)
   Local $nYear = 1970, $nMon = 1, $nDay = 1, $nHour = 00, $nMin = 00, $nSec = 00, $aNumDays = StringSplit ("31,28,31,30,31,30,31,31,30,31,30,31", ",")
   While 1
      If (Mod ($nYear + 1, 400) = 0) Or (Mod ($nYear + 1, 4) = 0 And Mod ($nYear + 1, 100) <> 0) Then; is leap year
         If $nPosix < 31536000 + 86400 Then ExitLoop
         $nPosix -= 31536000 + 86400
         $nYear += 1
      Else
         If $nPosix < 31536000 Then ExitLoop
         $nPosix -= 31536000
         $nYear += 1
      EndIf
   WEnd
   While $nPosix > 86400
      $nPosix -= 86400
      $nDay += 1
   WEnd
   While $nPosix > 3600
      $nPosix -= 3600
      $nHour += 1
   WEnd
   While $nPosix > 60
      $nPosix -= 60
      $nMin += 1
   WEnd
   $nSec = $nPosix
   For $i = 1 to 12
      If $nDay < $aNumDays[$i] Then ExitLoop
      $nDay -= $aNumDays[$i]
      $nMon += 1
   Next
   Return $nDay & "/" & $nMon & "/" & $nYear & " " & $nHour & ":" & $nMin & ":" & $nSec
EndFunc; ==> _GetDateFromUnix

Duco ergo sum

MDiesel

[KaFu]

The GetDateFromUnix() func is a nice addition , didn't find and good solutions while searching...

But your current timestamp doesn't seem to fit:

#include <Date.au3>
; Now
$iDateCalc = _DateDiff( 's',"1970/01/01 00:00:00",_NowCalc())
ConsoleWrite("_DateDiff " & @tab & $iDateCalc & @crlf)
ConsoleWrite("MDiesel " & @tab & ((@YEAR - 1970) * 31557600) + (int ((@YEAR - 1972) / 4) * 86400) + ((@YDAY - 1) * 86400) + (@HOUR * 3600) + (@MIN * 60) + @SEC & @crlf)

Edited July 2, 2009 by KaFu

[trancexx]

This is covered in EPOCH time, converting to and from thread in a more advanced and better way. I'm not saying that because it involves me, but just being objective really.

Just test mdiesel's function with EPOCH 123456789012345. It would take like forever.

Jos is doing that much better.

btw, there is just one little thing with one of my function and I corrected it for the needs of ResourcesViewerAndCompiler.au3. Inside that script the ultimate solution.

[KaFu]

This is covered in EPOCH time, converting to and from thread in a more advanced and better way.

Looks really good, will use it . Just didn't find it because the post is lacking the keyword 'Unix Timestamp' ...

[Mat]

I thought unix stamps could never reach that point, isn't it a signed 32bit integer? That only gives a range of -2,147,483,648 to 2,147,483,647, At least until we find a different method to store the data... see the 2038 problem

But you are right, mine is a very simple and makeshift method.

@Kafu

Found the reason for the miscalculation on my part. I was using 365.25 as the number of days in a year, and then adding leapyears on top... And then I was exactly 1 day ahead of you, so I just took a day off.

#include <Date.au3>
; Now
$iDateCalc = _DateDiff( 's',"1970/01/01 00:00:00",_NowCalc())
ConsoleWrite("_DateDiff " & @tab & $iDateCalc & @crlf)
ConsoleWrite("MDiesel " & @tab & ((@YEAR - 1970) * 31536000) + (int ((@YEAR - 1972) / 4) * 86400) + ((@YDAY - 2) * 86400) + (@HOUR * 3600) + (@MIN * 60) + @SEC & @crlf)

Non plaudite. Modo pecuniam jacite

MDiesel

Edit: you never saw this! Just seeing what the new forums do to this

[quote][__CODE_PROTECTED]JiM5MTthdXRvaXQmIzkzO2ZrZHNoZmtzIGtoaCBmZHNmc2sgJiM2MDsmIzMzOy0tZzEtLSYjNjI7JiM2MDtkaXYgY2xhc3M9JiMzOTtjb2RldG9wJiMzOTsmIzYyO0NPREUmIzU4OyBBdXRvSXQmIzYwOy9kaXYmIzYyOyYjNjA7ZGl2IGNsYXNzPSYjMzk7Z2VzaGltYWluJiMzOTsmIzYyOyYjNjA7JiMzMzstLWVnMS0tJiM2MjsmIzYwO2RpdiBjbGFzcz0mIzA5MjsmIzM0O2F1dG9pdCYjMDkyOyYjMzQ7IHN0eWxlPSYjMDkyOyYjMzQ7Zm9udC1mYW1pbHkmIzU4O21vbm9zcGFjZTsmIzA5MjsmIzM0OyYjNjI7JiM2MDtzcGFuIGNsYXNzPSYjMDkyOyYjMzQ7a3czJiMwOTI7JiMzNDsmIzYyO21zZ2JveCYjNjA7L3NwYW4mIzYyOyYjNjA7L2RpdiYjNjI7JiM2MDsmIzMzOy0tZ2MyLS0mIzYyOyYjNjA7JiMzMzstLWJYTm5ZbTk0LS0mIzYyOyYjNjA7JiMzMzstLWVnYzItLSYjNjI7JiM2MDsmIzMzOy0tZzItLSYjNjI7JiM2MDsvZGl2JiM2MjsmIzYwOyYjMzM7LS1lZzItLSYjNjI7IGZkc2Zkc2toJiM5MTsvYXV0b2l0JiM5Mzs=[/__CODE_PROTECTED][/quote]

Edited July 5, 2009 by mdiesel

[trancexx]

I thought unix stamps could never reach that point, isn't it a signed 32bit integer? That only gives a range of -2,147,483,648 to 2,147,483,647, At least until we find a different method to store the data... see the 2038 problem

But you are right, mine is a very simple and makeshift method.

@Kafu

Found the reason for the miscalculation on my part. I was using 365.25 as the number of days in a year, and then adding leapyears on top... And then I was exactly 1 day ahead of you, so I just took a day off.

#include <Date.au3>
; Now
$iDateCalc = _DateDiff( 's',"1970/01/01 00:00:00",_NowCalc())
ConsoleWrite("_DateDiff " & @tab & $iDateCalc & @crlf)
ConsoleWrite("MDiesel " & @tab & ((@YEAR - 1970) * 31536000) + (int ((@YEAR - 1972) / 4) * 86400) + ((@YDAY - 2) * 86400) + (@HOUR * 3600) + (@MIN * 60) + @SEC & @crlf)

Non plaudite. Modo pecuniam jacite

MDiesel

Fors fortis (ahaa!!! see that)

Check again.

And why wouldn't EPOCH time be over int?

[KaFu]

And why wouldn't EPOCH time be over int?

[Mat]

Trancexx, Cedo maiori, It would have to be stored in a different way, and so they are intending to change it by 2038, so yes it could reach that point, but by then we'll be using a new method, and will all own quantum computers (hopefully). My method doesn't do pre 1970 either.

Kafu, I knew that was a bad idea, kuckily ours broke before it could do any real damage.

MDiesel