Bug with Time Functions

After looking at the time functions more closely, can anyone explain why:

Second("00005:00006:00007") = 7
Minute("00005:00006:00007") = 6
Hour("0005:00006:00007") = 5

It looks like VB splits the time components then incorrectly cuts any leading zeros out of each time component. For example for:
hour = 00005 but then VB incorrectly removes leading zeros so hour then becomes:
hour = 5

In fact VB should remove a single leading zero if it exists i.e. 05 should become 5, but 005 should not become 5 it should produce an error.

Note that VB only removes leading zeros:
Second("00005:00006:000070")
Incorrectly VB reduces it to Second = 70 which produces an error as 70 > 59.

As a result are there API functions that can be used in place of these time functions, or do I just rewrite these functions in VB?

Regards

James

Someone must have come across this problem before?

Sorry, but I don't get you porblem.
Why do you need those leeding Zero'S.
I don't see a bug in VB since Seconds should be a Integer Value(at least I think so),
and what is the difference between 01 and 1?
If you need a String with leeding Zero's, make it yourself.

The problem is this:

Minute("04:30") = 30 and

Minute ("04:030") = 30 instead of 3

You don't consider this to be a problem?:confused:?

I wouldn't consider that an error either, if it's standard that 0's before numbers are automatically ignored, then i'd stick to the standard. However you could validate the time as follows:
valid = (yourtime like "##:##:##") and isdate(yourtime)

THAT IS A PROBLEM!
But it's not concerning leeding Zero's, it's because you accept strings that are not really
in the expected Time format (hh:mm:ss).
So check for that before you compute!
I normally use only one counter (for example seconds), and change it to a "hh:mm:ss"-String when needed
for a display.

Kedaman, that works perfectly.

I disagree that the time functions should accept invalid time data, though.

Time functions correctly reject "4:61" as invalid time data. If time functions only function correctly if passed valid 2 integer arguments for hour, minute and second, then time functions should also reject "4:0061" as invalid too. At least in my opinion anyway.

Time function returns the current time as date, and therefore no 0'es before the numbers are returned. Time function is not used to validate string as date, that's isdate's job. In case you want to accept 1 digit such as #:## or #:# you could check and invalidate 3 digits instead:
valid = not(yourtime like "*###*") and isdate(yourtime)

Kedaman, I wasn't talking about the time() function, but time functions generally. In particular I have been focusing on the hour(), minute() and second() functions.

When passed more than two integers with leading zeros, these functions return incorrect values as I illustrated previously, when they should pass an error instead. I still consider this a bug, because now I have to validate all time data before passing it to these functions, when these functions should deal with this problem internally.

I would never intentionally write a function that could return an incorrect value under any circumstance (probably have though :D).

Your workaround for the 'bug' works beautifully.

Okay nice, but just one thing to clear out.
Hour, minute and Second functions are innocent too, they just return the particular parts of a Date, which is the datatype you pass. Even this datatype is innocent, it doesn't return extra 0'es, the problem is (or what the standard is allowing) that the String to Date convertions ignores extra "0"es before the digits. String to Date convertions are done implicitely when you use Hour, minute or Second on strings, basically because you have to pass a Date, not a string.

Quote:

---

Originally posted by JamesM
I disagree that the time functions should accept invalid time data, though.

Time functions correctly reject "4:61" as invalid time data. If time functions only function correctly if passed valid 2 integer arguments for hour, minute and second, then time functions should also reject "4:0061" as invalid too. At least in my opinion anyway.

---

Um, they DO reject 4:0061 as invalid. :)
61 is still 61 :)

Lord Orwell, I made that point out in my initial post where I used 000070.

However, the user hasn't entered 61 mins, they have entered 0061 mins. It could be they are trying to enter a fraction of a minute ;).

Now is the time to raise an error, tell the user valid time data is two digits only as standard time data is hhmmss :).

if i want to enter fractions of minutes, i use seconds

I give up. I just want to stop users entering more than two digits for hours, minutes and seconds and optionally allow for am/pm suffixes, which to me seems prudent.

hmm, seems like i haven't forgot the stars anyway, look at my post, the one before my previous post.

Hmm that is a lot easier than what i had in mind. I was thinking of a user-defined data type in a class module that only accepted # 1-60 etc. Oh well :)

Kedaman, where'd you get that anigif of Marle for ur pic?
:D

tomcatexodus>

Quote:

---

Originally posted by Sastraxi
Yeah it is from CT, mine is too.
You can get one like it by typing in 'chrono trigger dance party' at www.yahoo.com

---

Lord Orwell>
The keyword is code reusage :)

Quick and easy way to keep people from entering more than 2 digits for H/M/S? If you're using TextBoxes, go ahead and set the MaxLength property to 2. This will kill any leading 0 problem. You can then, also write functions in the change event to keep a certain range going as well (If Val(Text1.Text) > 60 then Text1.Text = "60") ...

I'm just curious as to why 030 should return a 3. That confuses me. :) All standards for conversion from a string to a number reject all 0's before the number to the left of a decimal point, and if you had a decimal in there, everything afterwards would be ignored as well, returning a 0 (.030) as integers ignore the fractional part. Oh, well, i guess there's no use in beating a dead horse, eh?