time zone bias calculations
keycad1
TIME_ZONE_INFORMATION in the context of turning a SYSTEMTIME utc to and fro
local times. Sorry, not able to use CTime;(
If someone would kindly double check the math/flow, the msdn isn’t exactly
clear on calculating the total time zone bias.
TIME_ZONE_INFORMATION t_z_I;
SYSTEMTIME st;
// get and fill t_z_i code here;
// assuming standard / daylight bias is used… e.g. wMonth is non-zero in
// both the standard and daylight systemtime sub-structs of time_zone_info.
// the math;
int iTotalBias = t_z_i.Bais + t_z_i.StandardBias + t_z_i.DaylightBias ; //
Correct?
// get system time call..
GetSystemTime(&st);
// turn utc into local....
st.wMinutes += iTotalBias;
// now adjust the day, dayofweek, month, year... hair pulling code.
// everything ok... your opinion;)
if i may spread my humble opinion... someone at MS needs to be smacked in
the head for using words as the data type in the SYSTEMTIME struct. So much
for adding signed data types - adding negative minutes to wMinutes in the
context of daylight saving times... Spaghetti code, at least it tastes good.
<g>
set me strait and i'll post the class with a help file for public
consumption.
TIA
jason hummel
Chris Marriott
keycad1 wrote in message ...
That is a very BAD way to do it.
To do "arithmetic" on dates and times, call "SystemTimeToFileTime" to
convert the SYSTEMTIME to a FILETIME. FILETIMES are simple 64-bit integers.
Add/subtract the desired offset, then convert back to a SYSTEMTIME with
FileTimeToSystemTime.
Chris
-----------------------------------------------------------------------
Chris Marriott, SkyMap Software, UK (ch...@skymap.com)
Visit our web site at http://www.skymap.com
Astronomy software written by astronomers, for astronomers
Bernd Luevelsmeyer
>
> I’ve a bit ‘o drudgery… Trying to make a bit of sense out of the
> TIME_ZONE_INFORMATION in the context of turning a SYSTEMTIME utc to and fro
> local times. Sorry, not able to use CTime;(
>
> If someone would kindly double check the math/flow, the msdn isn’t exactly
> clear on calculating the total time zone bias.
>
> TIME_ZONE_INFORMATION t_z_I;
> SYSTEMTIME st;
>
> // get and fill t_z_i code here;
>
> // assuming standard / daylight bias is used… e.g. wMonth is non-zero in
> // both the standard and daylight systemtime sub-structs of time_zone_info.
>
> // the math;
> int iTotalBias = t_z_i.Bais + t_z_i.StandardBias + t_z_i.DaylightBias ; //
> Correct?
Of course you don't add the 'DaylightBias' if daylight saving isn't
active at the time in question.
> // get system time call..
> GetSystemTime(&st);
>
> // turn utc into local....
> st.wMinutes += iTotalBias;
I'd say you get local from UTC by subtracting the bias from UTC.
> // now adjust the day, dayofweek, month, year... hair pulling code.
mktime() comes to mind.
[...}
Have fun,
Bernd
keycad1
Chris Marriott wrote in message
<904031177.23807.4...@news.demon.co.uk>...
>
>keycad1 wrote in message ...
>>TIME_ZONE_INFORMATION in the context of turning a SYSTEMTIME utc to and
fro
>>local times. Sorry, not able to use CTime;(
>>
>>If someone would kindly double check the math/flow, the msdn isn’t
exactly
>>clear on calculating the total time zone bias.
[snip]
>
>
>That is a very BAD way to do it.
Yes, I agree, simply because most of the work has already been done in
another form. However, it’s not my choice, I must at the very least make a
modest attempt at this fashion before condemning it. Out of pure bliss, why
is this a bad way to do it? Making the assumption that ms coded the
TIME_ZONE_INFORMATION api's properly, the numbers will come up right. Or, at
least i am under the assumption that 95/98/NT uses these api's, it's self,
to calculate the machines local time... At least this would be a valid
reason to publish these kernel api's, otherwise there would be no reason to
have created them;) eh?
>
>To do "arithmetic" on dates and times, call "SystemTimeToFileTime" to
>convert the SYSTEMTIME to a FILETIME. FILETIMES are simple 64-bit integers.
This is exactly what i was told to stay away from and partially the
reason for the rewrite;) No matter how much i long to do it this way, i need
a very good reason why not to. How about two bullets, in case the first
fails to fire;) Portability is out of the window (no pun intended), it's
strictly a NT thing.
Roughly, i must create something close to the system agent but for
broadcast video. As in: firing tape decks, video routers and switchers,
ect... I am going to store these times/events in UTC form since they
can/will be created and performed from different locations in different time
zones via a tcp/ip network. As an added benifit, it will be much easier to
code/deal with timecode from one time reference - utc…
>Add/subtract the desired offset, then convert back to a SYSTEMTIME with
>FileTimeToSystemTime.
Best Regards,
jason hummel
Chris Marriott
keycad1 wrote in message
<205A08BE66C39941.1D8872E8...@library-proxy.airnews.ne
t>...
>
>>That is a very BAD way to do it.
>
> Yes, I agree, simply because most of the work has already been done in
>another form. However, it’s not my choice, I must at the very least make a
>modest attempt at this fashion before condemning it. Out of pure bliss, why
>is this a bad way to do it?
Because you're having to do all the "calendar arithmetic" yourself, rather
than letting the system do it for you. You need to get right the
calculations for the different numbers of days in a month, whether or not
it's a leap year, etc. By working with the time as a simple number (ie a
FILETIME) you're avoiding some VERY messy code. I speak from experience
here - there's a lot of "date arithmetic" in my astronomy software.
keycad1
Chris Marriott wrote in message
>
[snip]
>Because you're having to do all the "calendar arithmetic" yourself, rather
>than letting the system do it for you. You need to get right the
>calculations for the different numbers of days in a month, whether or not
>it's a leap year, etc. By working with the time as a simple number (ie a
>FILETIME) you're avoiding some VERY messy code. I speak from experience
>here -
>there's a lot of "date arithmetic" in my astronomy software.
....<g> i figured that much... Ok, ok... /* remove. foot. from. mouth. */
All right, another blissful question. Filetime uses 64bits, a given, how far
into the future is that going to get me? Isn't it based on the old dos time?
I really don’t know, i’ve always used systemtime when dealing with files
(spoiled rotten). SystemTimeToTzSpecificLocalTime will do just fine however,
the majority of the translations will be from local (arbitrary times) to
utc. I really half to be anal about sporting between a systemtime (that can
represent a greater span of time) into a filetime (64bits) and back again -
just to do the local to utc conversion… It’s the weak link in the chain (in
ms’s armor of api’s).
Quite honeslty, i finished 90% of the class two days ago, which does it the
hardway. It's now debug time before finishing the rest of the code. Big &
painful? Yes, but it is a one time thing. I just like the fact you can
compare local to utc and it hides the conversions in the background - and
can be given some basic concepts of timecode in a derived class.
imho, this does seem to be a reasonable code fragment…
BOOL Test()
{
xTime /* home brew class */ tLocal, tUtc;
tLocal.GetLocalTime();
tUtc.GetSystemTime();
/* automaticly converts tLocal to utc for comparison purposes only */
if(tLocal > tUtc)
return (TRUE);
else
return (FALSE);
}
Its not that bad!?
The class covers <, >, ==, !=, <=, >= operators.
This all leads me back to the original question... exactly, how does one
add standard bias and daylight bias in the time_zone_information to caculate
total bias? You know as well as i do, nothing is strait forward with ms or
their
documentation;) So what's the catch? Ignore the sign of standard and
daylight
bias and add them irregardless?
Best Regards,
jason
Ross Smith
<63E99E98A42FB532.AF164BFF...@library-proxy.airnew
s.net>...
>
> All right, another blissful question. Filetime uses 64bits, a given,
> how far into the future is that going to get me?
A Filetime is a count of 100-nanosecond intervals since January 1, 1601.
64 bits gives a range of 58,455 years, or up to AD 60,056.
--
Ross Smith ................................... mailto:ros...@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
"Remember when we told you there was no future? Well, this is it."
-- Blank Reg
Chris Marriott
keycad1 wrote in message
<63E99E98A42FB532.AF164BFF...@library-proxy.airnews.ne
t>...
>All right, another blissful question. Filetime uses 64bits, a given, how
far
>into the future is that going to get me?
About 60,000 years.
Pierre Abbat
//
> Correct?
No. You subtract Bias, then decide whether that time is in standard or
daylight, then subtract StandardBias or DaylightBias as appropriate.
> // get system time call..
> GetSystemTime(&st);
>
> // turn utc into local....
> st.wMinutes += iTotalBias;
Subtract, not add. First convert the entire date to a Julian day, and the
time to minutes or seconds, depending on your needs, then it will be easier
to calculate.
> // now adjust the day, dayofweek, month, year... hair pulling code.
The hair pulling code is figuring out when DST begins and ends from the
info in the structure. The Julian day conversion is already written (I got
it from the Forth Scientific Library; where it is in C I don't know).
> if i may spread my humble opinion... someone at MS needs to be smacked in
> the head for using words as the data type in the SYSTEMTIME struct. So
much
> for adding signed data types - adding negative minutes to wMinutes in the
> context of daylight saving times... Spaghetti code, at least it tastes
good.
If someone needs to be smacked in the head, it's for not making this
routine public in Windows 95! The routine obviously exists, since you can
get the local time.
phma