No announcement yet.

seconds since 1970

  • Filter
  • Time
  • Show
Clear All
new posts

  • seconds since 1970

    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$
        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
    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?
    Last edited by Shawn Anderson; 12 Nov 2007, 04:44 PM. Reason: forgot to ask...

  • #2

    Do you mean RtlTimeToSecondsSince1970?


    • #3
      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.



      • #4
        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
        Last edited by Guest; 12 Nov 2007, 05:51 PM. Reason: Getlocaltime


        • #5
          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!
          "The trouble with quotes on the Internet is that you can never know if they are genuine." - Abraham Lincoln.


          • #6
            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!
            Mike Luther
            [email protected]


            • #7
              Hey Shawn,
              Give this a try...

              #COMPILE EXE '#Win 8.04# #CC 4.04#
              #INCLUDE "" '#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
               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


              • #8
                #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


                • #9
                  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
                  Last edited by Roger Garstang; 13 Nov 2007, 10:15 AM.
                  Mobile Solutions
                  Sys Analyst and Development


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


                    • #11
                      UTC = what?

                      Originally posted by Roger Garstang View Post
                      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:
                      Gary Peek, Industrologic, Inc.


                      • #12
                        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)
                        Mobile Solutions
                        Sys Analyst and Development