Unix timestamp to VB Date
in [Visual Basic]
|
Prev: Archiving
Next: Problems shelling another application
From: Karl E. Peterson on 17 Dec 2009 16:35 on 12/17/2009, Rick Rothstein supposed : >>> 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> Well, the Good News is, I suppose, *none* of us will be alive to see it so you'll never have to make good on that bet. <g> -- ..NET: It's About Trust! http://vfred.mvps.org
From: Rick Rothstein on 17 Dec 2009 16:51 >>>> 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> > > Well, the Good News is, I suppose, *none* of us will be alive to see it so > you'll never have to make good on that bet. <g> Speak for yourself... I plan on being still here then. My plan is to live to be at least 200... so far, so good.<vbg> -- Rick (MVP - Excel)
From: Karl E. Peterson on 17 Dec 2009 16:59 Rick Rothstein has brought this to us : >>>>> 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> >> >> Well, the Good News is, I suppose, *none* of us will be alive to see it so >> you'll never have to make good on that bet. <g> > > Speak for yourself... I plan on being still here then. My plan is to live to > be at least 200... so far, so good.<vbg> Well, not that I'd be silly enough to bet against your prediction, mind you. <g> -- ..NET: It's About Trust! http://vfred.mvps.org
From: Tony Toews [MVP] on 17 Dec 2009 23:13 "Ralph" <nt_consulting64(a)yahoo.com> wrote: >Well at least none of them came out to 2012! Where's that cartoon showing the stone carvers. Caption is "Whattya say we go have a few beers?" Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/ Granite Fleet Manager http://www.granitefleet.com/
From: Karl E. Peterson on 18 Dec 2009 13:34
Karl E. Peterson submitted this idea : > Dee Earley submitted this idea : >> On 16/12/2009 15:44, Rick Rothstein wrote: >>> I think you can use this... >>> >>> VBdate = DateAdd("s", UnixTimeStamp, #1/1/1970#) >>> >>> where you would assign your Unix timestamp to the indicated variable. >> >> It's not that simple last I looked as we are currently dealing with numbers >> that have rolled over into negative values (using VBs signed longs) >> >> It shoudl be possible, but I never got code working properly as I just >> asked my colleague to change the format to a more VB friendly value :) > > Post bomb! <g> Sorry, but this got interesting for some reason. Check out > what I just found: But wait, there's more... http://en.wikipedia.org/wiki/Year_2038_problem Looks like the rest of the world knows, and doesn't particularly care, that we have a new Y2K38 bug lurking up on us. :-) -- ..NET: It's About Trust! http://vfred.mvps.org |