seconds since 1970

[Shawn Anderson]

I've been figuring seconds since 1970 for online transactions.
I've been figuring it using a function I wrote. For some reason, when we switch back and forth from daylight savings time, I have to adjust the GMT-x value.

This is how I'm doing it now:

FUNCTION secondsSince1970() AS LONG
    d$ = DATE$
    today&&=date2serial(d$)
    hippie&& = date2serial("01/01/1970")

    difference&& = today&&-hippie&&

    'this is the seconds to today
    grossSeconds&&= difference&&*86400 '((difference&&*24)*60)*60    'minutes for full days

    'now figure out the seconds of today
    t$ = TIME$
    lt&& =  VAL(PARSE$(t$, ANY ":", 1))* 3600   'hours to seconds
    mt&& =  VAL(PARSE$(t$, ANY ":", 2))* 60     'minutes to seconds
    rt&& =  VAL(PARSE$(t$, ANY ":", 3))         'seconds

    FUNCTION=grossSeconds&& + lt&& + mt&& + rt&&+21600  'I'm about 6 hours (GMT-6 = central standard time)
                                                        'short so add 18000 seconds back (5hrs) in : or 21600     
                                                        '(6hrs) depending on if in daylight savings time

END FUNCTION

I thought I saw somewhere here where there is an API call to do this which would probably be more efficient, but I can't find it.
Does anyone know of it?

Maybe what I should be asking is, is there a way to determine if the computer running this program is using daylight savings time?

[Guest]

Hi,

Do you mean RtlTimeToSecondsSince1970?

http://msdn2.microsoft.com/en-us/library/ms724928.aspx

[Shawn Anderson]

that looks like exactly what I need... the only problem being it is using pointers, the bane of my existence.

I'll give it a whirl.

Thanks!

[Guest]

Less elegant but does the job:

UNION quadfiletime
     ft AS filetime
     q AS QUAD
END UNION

     LOCAL st1, st2 AS systemtime
     LOCAL ft1, ft2 AS quadfiletime
     LOCAL secs_since_01_01_1970 AS QUAD
     getsystemtime st1
     st2.wday = 1
     st2.wyear = 1970
     st2.wmonth = 1
     systemtimetofiletime st1, ft1.ft
     systemtimetofiletime st2, ft2.ft
     secs_since_01_01_1970 = (ft1.q - ft2.q) / 10000000

Since you are using DATE$ in your example, you should use getlocaltime st1 instead getsystemtime st1.

Hope that helps

[Arthur Gomide]

I understand that daylight saving should not affect the counting of seconds of time elapsed since 1970, since they are not affected by seasonal variations of civil time. Elapsed time is elapsed time. Period!

[Mike Luther]

seconds since 1970

UTC, which this board is based on, has no such thing as Daylight savings time, grin! All you can do is properly leap to conclusions, chuckle.

An engineered time scheme is the mark of a civilization in decay, chortle!

[Pierre Bellisle]

Hey Shawn,
Give this a try...

#COMPILE EXE '#Win 8.04# #CC 4.04#
#INCLUDE "win32api.inc" '#2005-01-27#
 
DECLARE FUNCTION RtlTimeToSecondsSince1970 LIB "Ntdll.dll" ALIAS "RtlTimeToSecondsSince1970" _
                 (qTime AS QUAD, dwElapsedSeconds AS DWORD) AS LONG
                 'If the function succeeds, it returns TRUE
'______________________________________________________________________________
 
FUNCTION PBMAIN() AS LONG
 LOCAL qTime            AS QUAD
 LOCAL dwElapsedSeconds AS DWORD
 
 GetSystemTimeAsFileTime BYVAL VARPTR(qTime) 'Get current system time, UTC format
 
 RtlTimeToSecondsSince1970(qTime, dwElapsedSeconds) 'Get seconds elapsed since 1970
 
 ? "ElapsedSeconds since 1970/01/01..." & $CRLF & FORMAT$(dwElapsedSeconds, "###,") & " seconds"
 
END  FUNCTION
'______________________________________________________________________________

[Aleksandr Dobrev]

#COMPILE EXE
#DIM ALL
'
DECLARE FUNCTION SecSince1970 CDECL LIB "msvcrt.dll" ALIAS "time"(BYREF lTime AS LONG)AS LONG
'
FUNCTION PBMAIN () AS LONG
    '
    ? FORMAT$(SecSince1970(BYVAL 0),"#,")+" seconds elapsed since 01/01/1970"
    '
END FUNCTION

[Roger Garstang]

UTC= GMT with DST Shift (From your local perspective). I made a tool just to fix this issue with files and posted it in the Contest Forum. NTFS even shifts existing file date/time stamps on DST changes. If you use FILETIME you need to adjust it to keep with your count. Whichever way you do it...whether you want it to consider DST or if you want it not to. You either need it to adjust with it or negate it to keep the same count as though it doesn't occur, etc. Your timezone doesn't matter 100% since you are just counting seconds, as long as you use the same timezone or no timezone throughout.

Just using GetSystemTime for Current Time or GetFileTime for Files should give you the same unshifted count each time, but if locally you consider DST it will be wrong according to it. Any Local Translation with FileTimeToLocalFileTime, LocalFileTimeToFileTime, or GetLocalTime will be adjusted for both DST and your Timezone. To manually remove parts of the shift you need GetTimeZoneInformation to see if DST is in effect and shift whatever way you need. The best and easiest way to fix issues on a PC is to turn off DST shifting automatically then set the time yourself. Might even use Micro$oft's TimeZone Editor and completely remove the DST Dates, then nothing will be shifted behind the scenes. A little extreme, but it depends on what you need.

Union QuadTime
  Whole As Quad
  Parts  As FILETIME
End Union

Function HTTPtime(ByVal st As SYSTEMTIME, ByVal ifFiletime As Dword) As String
Local tz As TIME_ZONE_INFORMATION
Local TZbias As Long
Local FTvalue As QuadTime
Local d As Asciiz * 17
Local t As Asciiz * 13
Local tmpZ As Asciiz * 23

    If (GetTimeZoneInformation(tz)= %TIME_ZONE_ID_DAYLIGHT) And (tz.DaylightDate.wMonth <> 0) Then TZbias= tz.DaylightBias ' Daylight Savings Occurs
    If ifFiletime= 0 Then TZbias= TZbias + tz.bias 'file time is in UTC, just compensate for Daylight Savings Time

    SystemTimeToFileTime(st, FTvalue.Parts)
    FTvalue.Whole= FTvalue.Whole + (TZbias * 600000000)
    ' Max FT= &H7FFF35CB079677FF Fri, Dec 31, 30827 23:59:59 GMT
    FileTimeToSystemTime(FTvalue.Parts, st)
    'Wed, 28 Jan 2004 12:34:56 GMT
    tmpZ= "ddd', 'dd' 'MMM' 'yyyy"
    GetDateFormat MakDwd(MAKELANGID(%LANG_ENGLISH, %SUBLANG_ENGLISH_US), %SORT_DEFAULT), 0, st, tmpZ, d, 17
    tmpZ= "HH':'mm':'ss' GMT'"
    GetTimeFormat MakDwd(MAKELANGID(%LANG_ENGLISH, %SUBLANG_ENGLISH_US), %SORT_DEFAULT), 0, st, tmpZ, t, 13
    Function= d + " " + t
End Function

[Shawn Anderson]

Aleksandr,
That's what I was looking for. I think it has been posted here somewhere before.
Thanks all - good information all around.

[Gary Peek]

UTC = what?

UTC= GMT with DST Shift (From your local perspective).

Wow, Roger, that's not my understanding of UTC. Everywhere I were in search of a definition says exactly what Wikipedia does:

http://en.wikipedia.org/wiki/Utc

[Roger Garstang]

Yeah, that is why I added the () Description after it. I wanted to show that the 2 were the same, but you still needed to reverse the DST that getting the Local time added. I had in some notes from some time ago that UTC had DST Built in, but the source was incorrect and now says that it has Leap Seconds. The previous notes snuck in when I posted.

As far as I know...unless using the API to speed up/slow down seconds/time(SetSystemTimeAdjustment) Windows doesn't do Leap Seconds, so even though it says UTC in the Documentation it can be assumed that GMT=UTC, UTC=GMT. Either way you still need to adjust for your local TimeZone and DST if you want them to match the current time in your area.

How I should have worded it was UTC= GMT (If you use DST Adjustments to reverse their effects)