Getting Current UTC

[Stuart McLachlan]

Tidied up functions for UNIX TimeStamp, FileTime seconds and current UTC ISO DateTime as strings, all with optional fractional seconds (up to msecs)

'

Code:

' Current Unix Time, FileTime seconds and ISO UTC DateTime
' to a maximum of 3 decimal places!!!
#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG
    LOCAL s AS STRING
    ? "UnixTime:" & $LF & UnixTimeNowStr & $LF & UnixTimeNowStr(1) & $LF & $LF _
      & "Filetime: " & $LF & FileTimeNowStr & $LF & FileTimeNowStr(2) & $LF & $LF _
      & "ISO DateTime: " & $LF & ISONowUTCStr & $LF & ISONowUTCStr(3) & $LF,, "UTC TimeStamps"
END FUNCTION

FUNCTION UnixTimeNowStr((OPT BYVAL decplaces AS LONG) AS STRING
    LOCAL tmpTime AS IPOWERTIME, fmt AS STRING
    fmt = "0"
    IF decplaces > 3 THEN decplaces = 3
    IF decplaces > 0 THEN fmt &= "." & STRING$(decplaces,"0")
    tmpTime = CLASS "PowerTime"
    tmptime.nowUtc
    FUNCTION = FORMAT$(tmpTime.filetime/10000000 - 11644473600,fMt)
END FUNCTION

FUNCTION FileTimeNowStr(OPT BYVAL decplaces AS LONG) AS STRING
    LOCAL tmpTime AS IPOWERTIME, fmt AS STRING
    tmpTime = CLASS "PowerTime"
    tmptime.NowUTC
    fmt = "0"
    IF decplaces > 3 THEN decplaces = 3
    IF decplaces > 0 THEN fmt &= "." & STRING$(decplaces,"0")
    FUNCTION = FORMAT$(tmpTime.Filetime /10^7,fmt)
END FUNCTION

FUNCTION ISONowUTCStr(OPT BYVAL decplaces AS LONG) AS STRING
  LOCAL tmpTime AS IPOWERTIME, s AS STRING
    tmpTime = CLASS "PowerTime"
    tmptime.NowUTC
    s = CHR$(FORMAT$(tmpTime.Year,"0000"),FORMAT$(tmpTime.Month,"00"),FORMAT$(tmpTime.Day,"00"),"T", _
              FORMAT$(tmpTime.Hour,"00"),FORMAT$(tmpTime.Minute,"00"),FORMAT$(tmpTime.Second,"00"))
    IF decplaces > 3 THEN decplaces = 3
    IF decplaces > 0 THEN s &= "." & FORMAT$(CINT(tmpTime.msecond/10^(3-decplaces)))
    FUNCTION = s & "Z"
END FUNCTION
'

[Dale Yarker]

Was thinking along similar lines as Eric; we're in a Windows environment. But found post 10 compelling. Updating to OPT parameters is logical too.

Suppose the 'ux timestamp is kept in binary for sorting and duration, then string form is needed later? Back to Powertime/filetime then Powertime methods/filetimetosystemtime?

(Only a bit, but some of the opening is butter because I don't need it, so am too lazy to do itmyself!  ))

[Dale Yarker]

Additional thought on timestamps:

On one hand Windows has Filetime, and we work in Windows.

On the other hand 'ux time is used/supported as "standard".

On the gripping hand, maybe it is the 'ux that should upgrade to be compatable:

"What happens on January 19, 2038?
On this date the Unix Time Stamp will cease to work due to a 32-bit overflow. Before this moment millions of applications will need to either adopt a new convention for time stamps or be migrated to 64-bit systems which will buy the time stamp a "bit" more time."

"Systemtime range and practical limit of filetime 1 January 1601 to 14 September 30828, 02:48:05.4775807"

Filetime will last 15 times more years remaining, epoch earlier, and 10^7 times better resolution.

[Stuart McLachlan]

Additional thought on timestamps:

On one hand Windows has Filetime, and we work in Windows.

On the other hand 'ux time is used/supported as "standard".

On the gripping hand, maybe it is the 'ux that should upgrade to be compatable:

"What happens on January 19, 2038?
On this date the Unix Time Stamp will cease to work due to a 32-bit overflow. Before this moment millions of applications will need to either adopt a new convention for time stamps or be migrated to 64-bit systems which will buy the time stamp a "bit" more time."

"Systemtime range and practical limit of filetime 1 January 1601 to 14 September 30828, 02:48:05.4775807"

Filetime will last 15 times more years remaining, epoch earlier, and 10^7 times better resolution.

Another Motie, eh?

Unix Timestamp will only "cease to work" i.e. overflow if it is calculated/represented as a LONG. Use a DWORD instead and you get another 68 years. 

The UnixTimeNowStr above has the same maximum  14 September 30828 upper limit as FileTime

Many systems are already using an Int64 and I doubt the there will be many systems still using an int32 in 12 years time. 
Use a Quad and you get over 282 billion years 
That should be enough for Eric's "cosmologist working on the age of the universe,"

[Stuart McLachlan]

Best of both worlds, UnixTimeStamp with almost the range of a Filetime 
(1 Jan 1601 to 31 Dec 30827) 

'

Code:

'Unix TimeStamp with one second resolution and almost the range of a filetime (1 Jan 1601 to 31 Dec 30827)
#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG
  LOCAL lDebug AS LONG: TXT.WINDOW EXE.FULL$, 10,10,45,85 TO lDebug

  TXT.PRINT "Now: " & STR$(UnixtimeNowQ())
  TXT.PRINT  STR$(unixtimeQ(1601,1,1,23,59,59))
  TXT.PRINT STR$(unixtimeQ(1970,1,1,0,0,0))
  TXT.PRINT  STR$(unixtimeQ(30827,12,31,23,59,59))

  TXT.COLOR = %RGB_BLUE:TXT.PRINT:TXT.PRINT "  ....Press any key to exit": TXT.WAITKEY$: TXT.END
END FUNCTION

FUNCTION UnixTimeNowQ() AS QUAD
    LOCAL tmpTime AS IPOWERTIME
    tmpTime = CLASS "PowerTime"
    tmptime.nowUTC
    FUNCTION = tmpTime.filetime/10000000 - 11644473600
END FUNCTION

FUNCTION UnixTimeQ(y AS LONG,m AS LONG,d AS LONG, h AS LONG,mm AS LONG,s AS LONG) AS QUAD
    'Input local time, output UTC based on current UTC offset
    LOCAL tmpTime AS IPOWERTIME
    tmpTime = CLASS "PowerTime"
    tmptime.newdate(y,m,d)
    tmptime.newtime(h,mm,s)

    'debug code - comment out next line for normal function use
    TXT.PRINT tmpTime.datestring & " " & tmptime.timestringfull,

    tmptime.toUTC
    FUNCTION = tmpTime.filetime/10000000 - 11644473600
END FUNCTION
'