Field to enter ONLY time. (1 Viewer)

@June7
Your test is correct, but that is not what the OP is doing. As you said if you enter a time component only with no integer portion then when you click in the text box it will only show the time.
However, for some Unexplained reason the OP is entering a date (integer) portion with an integer value of 2.
And when you go into the table or another datasheet form with those fields, they are showing 01/01/1900 14:00:00
The OP has a day portion and it is the integer value of 2. Not even 1.
When you enter 14:00:00 you are saving the value
0.583333333333333
the OP is saving the value
2.583333333333333

?cdate(2.583333333333333)
1/1/1900 2:00:00 PM

?cdate(.583333333333333)
2:00:00 PM

?cdate(0)
12:00:00 AM

?cdate(1)
12/31/1899

?cdate(2)
1/1/1900

@Jen-Jen To ensure you never see a date portion when you click into a cell, on the after update of the field do the following.
Me.fieldName = Me.fieldName - int(me.fieldName)

The bigger question is why you are adding 2 days.
 
Last edited:
And that is as it should be. It is a mistake to use a format at the table level in an attempt to hide the true value of the table column. You could get a huge dent in your head and loose all your hair after days of debugging when you do this to yourself. NEVER format data in a table. PERIOD.
The format does not change the stored value. It merely hides it from you.
So you will drive yourself crazy trying to figure out why the two values that look like 2:30 are not identical.

The date/time data type is a "point in time" and time includes date. If the user must enter the time you probably won't run in to trouble with data values if you add some proper validation to the form's BeforeUpdate event. But if you use Now() to populate the field, you are in a world of hurt if you ever expect to compare two values because 2:30 PM may in fact not be exactly 2:30 since the date value is a double precision number and it is actually rounded to minutes and seconds for display but does not represent the actual stored value. Given that, I also store time as a string.
I think that's the best summation of the situation I've seen.
 
The point being covered here by some and ignored by some is that the date/time data type is exactly that and the time element is a date fraction. If all you are interested in is time values then it is the wrong data type!
 
I might disagree slightly, DickyP - a date/time variable is the easiest way to fiddle with time - if you just understand that there is a helper AND a barrier to force your hand. The helper is that Office manipulates time pretty much uniformly across all its platforms. The reference point might change (1/1/1900 or 12/30/1899 or other reference points as they occur) but they are TIMELINES - a number representing an elapsed time excursion from start time to finish time.

This makes time easy in one way, because #10:45# is an unequivocal time - as is #12:34:56# or #00:00:00#. But the problem actually lies with the date/time FORMAT routines. THEY are the source of the problem. They will not work with fractions of a second, and if you accumulate more than 24 hours of time, there is no format such as "hhhh:mm" (long number of hours, normal minutes). It is the formatting that complicates time.
 
and if you accumulate more than 24 hours of time, there is no format such as "hhhh:mm" (long number of hours, normal minutes). It is the formatting that complicates time.
That is because the date/time data type is a "point in time". It is useful for entering when something did or will happen. But if you want to calculate elapsed time, you need to convert to straight minutes or seconds depending on the precision you want in the result.
 
That is because the date/time data type is a "point in time". It is useful for entering when something did or will happen. But if you want to calculate elapsed time, you need to convert to straight minutes or seconds depending on the precision you want in the result.

Agree - which is why "roll your own time function" is a common answer to people with time-display problems.
 

Users who are viewing this thread

Back
Top Bottom