From: Karl E. Peterson on
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
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

"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
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
>> 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)

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Archiving
Next: Problems shelling another application