Unix timestamp to VB Date
in [Visual Basic]
|
Prev: Archiving
Next: Problems shelling another application
From: Karl E. Peterson on 17 Dec 2009 15:22 Rick Rothstein formulated on Thursday : > Changing the argument of your NetTimeToVbTime function from Long to Variant > and replacing your VbTimeToNetTime function with the following appears to > make them both work through to 12/31/9999 (I think)... > > Public Function VbTimeToNetTime(ByVal VbDate As Date) As Variant > VbTimeToNetTime = CDec(DateDiff("s", BaseDate, VbDate)) > End Function > > Oh, look, a one-liner. <g> Slick. <g> Butt... Most functions (including Win32) that provide or consume net/unix times are offering/expecting a DWORD. If you were working with one that didn't have that restriction, this'd be a GOTO. <bg> It'd actually be interesting to try setting a password expiration at some point a century+ from now, to see how Windows would react. -- ..NET: It's About Trust! http://vfred.mvps.org
From: Rick Rothstein on 17 Dec 2009 15:28 The last time I worked with a UNIX system was 1988 or so... all I was doing here was reacting off the code you posted... I have/had no idea whether it would work or not (hence, the qualifying words "appears" and "I think"). -- Rick (MVP - Excel) "Karl E. Peterson" <karl(a)exmvps.org> wrote in message news:eU3jea1fKHA.2184(a)TK2MSFTNGP04.phx.gbl... > Rick Rothstein formulated on Thursday : >> Changing the argument of your NetTimeToVbTime function from Long to >> Variant and replacing your VbTimeToNetTime function with the following >> appears to make them both work through to 12/31/9999 (I think)... >> >> Public Function VbTimeToNetTime(ByVal VbDate As Date) As Variant >> VbTimeToNetTime = CDec(DateDiff("s", BaseDate, VbDate)) >> End Function >> >> Oh, look, a one-liner. <g> > > Slick. <g> > > Butt... Most functions (including Win32) that provide or consume net/unix > times are offering/expecting a DWORD. If you were working with one that > didn't have that restriction, this'd be a GOTO. <bg> > > It'd actually be interesting to try setting a password expiration at some > point a century+ from now, to see how Windows would react. > > -- > .NET: It's About Trust! > http://vfred.mvps.org > >
From: Ralph on 17 Dec 2009 15:26 "Nobody" <nobody(a)nobody.com> wrote in message news:OvIsA40fKHA.1536(a)TK2MSFTNGP06.phx.gbl... > "Ralph" <nt_consulting64(a)yahoo.com> wrote in message > news:uCEc6PxfKHA.1652(a)TK2MSFTNGP05.phx.gbl... > > Many "Unix Timestamps" are GMT So you need to go piddle with time zones as > > well. > > http://www.trap17.com/index.php/Converting-Unix-Timestamp_t20240.html > > > > Also as a minor warning to the OP, within any shop that is using "unix" > > with > > other services such as Oracle or PHP there may be a common critter > > everyone > > is passing around calling a "Unix TimeStamp", but in reality it might be > > based one of several established "Time" formats. Always ask before going > > off > > and making assumptions, can save a lot of *time*. <g> > > The time zone conversion in the link you posted doesn't do it correctly. It > doesn't handle daylight saving, and few other cases. The code need to check > the return value and add other bias values based on the return value. See > GetCurrentTimeBias() function in this VB6 sample: > > http://vbnet.mvps.org/code/locale/gettimezonebias.htm > > Another way to convert between local and UTC is using > FileTimeToLocalFileTime/LocalFileTimeToFileTime to do the conversion. They > do all the work. VB's Date can be converted to these structures using > Year/Month/Day/Hour/Minute/Second functions and SystemTimeToFileTime(). To > convert back, use FileTimeToSystemTime(), then DateSerial() + TimeSerial(). > lol, that's the second time I've recently posted URLs with code based purely on 'subject' that I didn't check. I might have caught the DayLight problem, but not the other issue. Thanks for catching and correcting. -ralph
From: Karl E. Peterson on 17 Dec 2009 15:49 Rick Rothstein presented the following explanation : > The last time I worked with a UNIX system was 1988 or so... all I was doing > here was reacting off the code you posted... I have/had no idea whether it > would work or not (hence, the qualifying words "appears" and "I think"). Yeah, it's been forever for me, too. But Windows is similarly afflicted. Check out the usri3_last_logon, usri3_last_logoff, and usri3_acct_expires elements of USER_INFO_X structures: http://msdn.microsoft.com/en-us/library/aa371338%28VS.85%29.aspx It looks like they're attempting to address this, but I see a bit of a problem ahead for any systems that folks manage to keep hobbling along long enough. <g> http://www.google.com/search?q=site:msdn.microsoft.com+January+1%2C+1970 -- ..NET: It's About Trust! http://vfred.mvps.org
From: Rick Rothstein on 17 Dec 2009 16:23
>> The last time I worked with a UNIX system was 1988 or so... all I was >> doing here was reacting off the code you posted... I have/had no idea >> whether it would work or not (hence, the qualifying words "appears" and >> "I think"). > > Yeah, it's been forever for me, too. But Windows is similarly afflicted. > Check out the usri3_last_logon, usri3_last_logoff, and usri3_acct_expires > elements of USER_INFO_X structures: > > http://msdn.microsoft.com/en-us/library/aa371338%28VS.85%29.aspx > > It looks like they're attempting to address this, but I see a bit of a > problem ahead for any systems that folks manage to keep hobbling along > long enough. <g> > > http://www.google.com/search?q=site:msdn.microsoft.com+January+1%2C+1970 I guess this all made sense in the 1970's (yeah, I know, 1969 for the date UNIX was created) when the "drop dead" date was so far away... but now that "drop dead" date is starting to get close enough that someone should start doing something about it (rather than waiting to the very end like was done with the "millennium bug"). My bet... they will wait to the very end.<g> -- Rick (MVP - Excel) |