Re: date Conversion Program in Assembly


Guga wrote:
> Randall,
>
> I´m not sure if your functino is for DOS, but....
>
> If it is not..i mean, if the library uses an api...Why having to do 03
> operations, and onlylater having to use another library to print the
> result ?
>
> I didn´t understood why you are dividing and using the mod operation ?
>
> All he need to do is have his value in a Dword form and set the High
> and low parameters to the proper structure. The rest is the work of the
> API that will return either the Date or Time string formats.

The input is a decimal number, not hex. He *could* write special input
routines to extract the digits of the date components individually, but
unless you're doing a *lot* of date validations, you trade dubious
performance benefits for a lot of extra work. No doubt, this is a
school project.

>
>
> If he input his DateTime Stamp only as
>
> 03836401D

That's not the format. Look at again, it's DDMMYYYY with DD, MM, and
YYYY in decimal form (or, at least, that's what I infer from the
example in the post). Sure, if it was input in hex format, you could do
the mod/div 16 trick rather than mod/div 10 trick and just pick off the
bytes in the dword input. But this isn't the input format as best I can
tell.


>
> And choose the proper formats for his output Date and Time. Let´s
> say...
>
> [Sz_Year: B$ "yyyy/MM/dd ddd ",0] ; Date
> [Sz_Hour: B$ "HH:mm:ss UTC",0] ; Time
>
> The output is already on DateOut, TimeOut parameters of the function.
> He don´t need even to convert it to be printed, because the output is
> already in Ascii Null terminated string.

Maybe I missed something. I was under the impression that the output
date format had to be 'February, 15, 1999'. Now granted, one *could*
read the values in as a hex string, extract the H.O. bytes and use the
(converted hexadecimal) value for the month as an index into an array
of strings to extract "February" and then you can print the other two
values as BCD using a hexprint routine, but this is exactly the kind of
"specific" programming nonsense that comes back to bite you in the ***
later on. The purpose of an exercise like this is *not* to convert a
string of digits like "15021999" to a string like 'February, 15, 1999'.
Who needs an application like that? It's more likely a programming
exercise intended to teach some valid programming techniques. And
*most* programs that deal with dates often do other computations on
those dates beyond a string conversion. Using an approach that can
*only* be used for string conversion dramatically limits what you can
do with the code afterwards, and, therefore, what you've learned from
this whole process. For example, suppose next weeks' project is to
compute the number of days between two dates. All of a sudden, that
"quick and dirty" specific version is useless for the next project. But
the project that was done correctly forms the basis for the new
project.

>
> So, basically, all he need is the original DWORD value for his TameDate
> Stamp. If he enter the value above, the output are already given for
> him by the Api function.
>
> Input: 03836401D
>
> OutPut Date: 1999/11/20 sab
> OutPut Time: 06:30:53 UTC

Again, the input is not in Hex, but even if you input it as BCD and
pulled some tricks, you've still got a specific solution, rather than a
generic solution. Which is *fine* if all you're ever going to do is
convert strings like 15021999 to 'February, 15, 1999', but it comes
back to haunt you if you need to do additional work.

>
>
> Why do you have to use a mod/div/mod/div/call date.validate - that
> probably will go onto the same api-/ call date.setFormat/data.toString
> - that didn´t needed to convert to Ascii Null string, because the api
> already does it.

The mod/div stuff is just the standard way to break a *decimal* number
like 15021999 into consitutent parts like 15, 02, and 1999. You're
doing the same thing by extracting bytes, but the base is 16 rather
than 10.


>
> I didn´t understood why those operations are involved, instead using
> the api almost directly.

If there is an API that accepts the data in exactly the stated format,
you're correct. I'm not aware of that.
Cheers,
Randy Hyde

.