Prev: Error 480 - can't create autoredraw image
Next: VB6 FileCopy Fails Windows XP SP2
From: expvb on 19 Oct 2006 19:35
This Epoch time is not so easy it seems. It's in UTC, and not counting leap
seconds according to this article:

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

So, you may want to use GetSystemTime() to get the time in UTC, and use
DateSerial/TimeSerial to convert it to Date data type, then use DateDiff()
as others suggested, then handle the leap seconds.

Finally, as far as I know, when using #date# constant, the compiler will
interpret it at compile time using the Control Panel settings. If you use
"date", it will be interpreted at runtime depending on the end user's locale
settings. This means that it's better to use the #date# format, but it has
one problem: if you share the source code with someone else with different
locale settings, then you get a problem. To be sure, use
DateSerial/TimeSerial functions.

Sample code:

Option Explicit

Private Type SYSTEMTIME
wYear As Integer
wMonth As Integer
wDayOfWeek As Integer
wDay As Integer
wHour As Integer
wMinute As Integer
wSecond As Integer
wMilliseconds As Integer
End Type
Private Declare Sub GetSystemTime Lib "kernel32" (ByRef ust As SYSTEMTIME)

Private Sub Form_Load()
Dim SysTime As SYSTEMTIME
Dim dSysTime As Date
Dim EpochTime As Long

GetSystemTime SysTime

' Create a date/time value from the system time parts
With SysTime
dSysTime = DateSerial(.wYear, .wMonth, .wDay) + TimeSerial(.wHour,
..wMinute, .wSecond)
End With

' Does not account for leap seconds
EpochTime = DateDiff("s", #1/1/1970#, dSysTime)

Debug.Print dSysTime, EpochTime
End Sub




From: Bob Butler on 19 Oct 2006 21:08
"expvb" <nobody(a)cox.net> wrote in message
news:ejHH0c98GHA.2128(a)TK2MSFTNGP05.phx.gbl
<cut>
> Finally, as far as I know, when using #date# constant, the compiler
> will interpret it at compile time using the Control Panel settings.

If you mean the #mm/dd/yyyy# format then no, the compiler treats it as
#mm/dd/yyyy# format.

> If you use "date", it will be interpreted at runtime depending on the
> end user's locale settings.

If you mean the Date function then it isn't interpreted at all; it's in VB's
internal Double format. It will be *displayed* according to the locale
settings but that's entirely different. If you do Msgbox #1/2/2006# then
you might see 1/2 or 2/1 depending on locale settings but it'll be Jan 2.

> This means that it's better to use the
> #date# format, but it has one problem: if you share the source code
> with someone else with different locale settings, then you get a
> problem.

No problem

> To be sure, use DateSerial/TimeSerial functions.

Those'll work too

--
Reply to the group so all can participate
VB.Net: "Fool me once..."

From: Bob Butler on 19 Oct 2006 21:24
"Stefan Berglund" <sorry.no.koolaid(a)for.me> wrote in message
news:d0cfj25rb8haapeklnumqub16uhuaimhuc(a)4ax.com
<cut>
> How does that avoid the ambiguity? Doesn't it still rely on locale
> settings and so would be different on different machines?

I just tested this by changing my date display to "dd/MM/yyyy" and running
this code:
Dim d As Date
d = #1/2/2006#
MsgBox d & vbCrLf & Month(d)

The message showed 02/01/2006 and 1

I changed the settings back to "M/d/yyyy" and ran the same code and the
message shows 1/2/2006 and 1

--
Reply to the group so all can participate
VB.Net: "Fool me once..."

First  |  Prev  | 
Pages: 1 2 3
Prev: Error 480 - can't create autoredraw image
Next: VB6 FileCopy Fails Windows XP SP2