Well, I have found one answer to my own question. It allows you to enter 1300 and it changes it to 1:00 PM internally while still displaying 1300, which is almost exactly what I want. This seems to work, although when you click in the field to edit the time, it displays 12 hour format, which can be confusing to people. I am trying tp decipher how I can just let the time to remain in 24 hour format.
If you can constrain the entry using a pull-down, the easiest way to deal with this is to disallow keyboard entry and just give the user a value list to work with (similar to the scroll wheels used in iOS). Allow them to enter the hour and minutes as numbers and internally put it into a second time field. Solves the issue of users wanting to enter "1300" instead of "13:00".
Just a thought...
YOU know it is time...THEY know it is time...FMP doesn't need to know...
Why not just use a number field instead of a time field?
For time calculations...you have the Time() function
When you have to enter this times:
what do you usually want to type ?
I would not want to use a pull down, or drop up, etc. Speed is of essence here. These are phone operators reservationists and and dispatchers, so need they need a very fast and efficient input method.
They would type 0110 for 01:10 and 0101 for 01:01. We do not enter seconds, so it's just hhmm.
An approach that hasn't been mentioned: use a script trigger OnObjectValidate, and you can pretty much enter whatever you like (AM/PM, no delimiters, nifty abbreviations …), as long as what eventually gets committed & validated is a valid time as Filemaker understands it.
Ensuring that this is so would be a matter of your triggered script calculation.
Well, FMP DOES need to know it's time, in the sense that we do use this time of day to do other calculations and look up things in other tables that are based on time of day. For example a dispatcher needs to know what driver is on duty, by looking at the time of day recorded in the trip reservation and then look into table that has the driver shift schedule and present all drivers that are available at the time of day.
I may be wrong but I don't think that the Time() function would work for me. Doesn't the Time() function just convert numbers into DURATION of time? What I need is for numbers to be dealt with as TIME OF DAY.
So for example:
Time(4;14) returns 4:14
I don't think FMP will threat this at 4:14 AM, correct? It just sees that as a duration of 4 hours and 14 minutes.
Also isn't the Time function expecting Time(hours;minutes)? So how would it read a value such as 1341 entered into a field? Are you suggesting I parse the value, taking the first 2 digits as hh and the last 2 as mm? I would not wan to do that in EVERY time field calculation that I am doing. We have a lot of them.
No, it sees it as 4:14 AM.
You can solve this by using a text field and parsing it into a time field independently. If you can rely on your operators always entering 4 digits, it's:
Time ( Left ( textField ; 2 ) ; Right ( textField ; 2 ))
I would put some entry traps in there to ensure the entry meets requirements, but a second field should meet your needs.
Yes, I would use a Text field (otherwise your leading 0's could be lost , example - 00:01 or 0001)
the SORTING would be absolutely accurate for "time of day".
if you need this converted to "time" then there are way to do that.
GetAsTime( quote( left(timefield;2) & ":" & right(timefield;2) ) )
should do this.
and you may wish for an auto-enter (or calc field stored) to equal this and use the new field in calculations or elsewhere. Just use the text field for entry and display.
Just keep the timefield and enter the time as 1325 or so for 1:25 PM and have an auto-enter format the time for you:
Let ( [
t = Round ( GetAsNumber ( Self ) / 3600 ; 0 ) / 100 ;
h = Int ( t ) ;
m = Int ( ( t - h ) * 100 )
If ( PatternCount ( Self ; ":" ) = 0 ; Time ( h ; m ; 0 ) ; Self )
The result should look after you leave the field like 13:25:00 or 1:25 PM
FileMaker Pro has a Field of Type Time. It is a display in time format of a numeric value.
It does not inherently mean time of day or duration. That is an interpretation of the displayed value.
So its entirely up to you what it means and how you use it.
Data entry is the same thing. You enter 1300 and it means either Time-of-day is 1 PM or it means 1300 seconds, or it means 13 minutes and 00 seconds, or 13 hours and 00 minutes. The meaning of this data is not intuitive and it is not part of the field types definition.
For a duration time entry you could have two digits for each value. For example: HHMMSS
You've started the entry will be HHMM. BUT, how certain are you they will adhere to that input? They could enter 130 to mean 1 hour and 30 minutes. I bring this up to illustrate the issues of interpreting the data entry.
For example the first value could be 1 or 2 numbers while the second will probably always be 2 values. But what if the value is just two digits" Do we assume it's only minutes? Since the first value might be a zero as in 030 = 0 minutes and 30 seconds you also should make the data entry field text not time or number. Time and number may remove the leading zero when evaluated in a calculation and potentially change the 'length' of the input.
As a text field you have more control over the characters entered.
I suggest something like this as an auto enter Calculation to reformat the field value as HHMM.
input_data = Self ;
data_length = Length ( input_data ) ;
data_minutes = Right ( input_data ; 2 ) ;
data_hours = Left ( input_data ; data_length - 2 ) ] ;
Right ( "00" & data_hours ; 2 ) & ":" & Right ( "00" & data_minutes ; 2 )
You can make this a Custom Function by removing the "input_data = Self;" and making the value "input_data" the input variable to the CF.
Note: I didn't test the calculation so it may have a typo that would prevent it from working as-is.
I created a little example (TimeEntry.fmp12) to the formula I posted here. You can can enter times in the fashion as you mentioned earlier: 1325 for 1:25 PM. I added an offset, so that when 4:30 PM is entered as 430 the calc will interpret that as 16:30
There is a strange side-effect though with the system-formats. I've made the file's native system-format US-computer and if your computer is set to a different format ... "use system-format" (USF) is usually switched on (I've killed that with a script-trigger here) and if that happens the calculation seems not to work properly (which is demonstrated in the second file (TimeEntry_NL.fmp12) which has NL settings and no script-trigger to switch USF of)
Thanks everyone. Lots of good suggestions. I am playing around to see what works best for us.