Hi there,

 

I'm currently developing an ongoing solution where I have used decimal times.

ie. 1.5 = 1hr 30mins, 3.75 = 3:45 etc.

 

The reason I used decimal was clear to me at the time   but now I would like to dispay the resulting calculation in "proper" time format.

 

I could probably nut it out using some convoluted method but was hoping that someone has a more elegant solution.

 

Cheers,

Steve.

You could take everything after the decimal  x .6

thus  .75 x .6 = .45

drop the decimal and add it to th first part of the number

Hi Steve, and welcome to the Forum.

 

I moved your topic from "FileMaker Legacy fp3 and fp5" to "Calculation Engine (Define Fields)".

 

The General Topics areas are for asking questions about the tools, functions and features that were new with that release of FileMaker, and not for asking how-to questions.

 

Lee

If you are using an additional calculated time field to display in time format, this calculation will work for you:

timeAsHoursDecimal * 60

 

A FileMaker time field stores time as a number of seconds.

Thanks all.

 

dansmith, your solution was what I was after, with a minor tweak:

timeAsHoursMinsDecimal * 60 * 60

Then formatted in 24hr notation as Hrs:Mins

 

Seems to work just fine - I all makes sense now, I think.

 

I took the time to go back to the related table and realised that I originally divided the time by 60 to get to decmal!!

The reason being that the number had to be multiplied by "$hourlyRate" which I didn't think would work with time format. ie "time * $hourlyRate"

 

But It may well work fine that way, and just shows my ignorance and inexperience.

 

Anyway, the upshot is at worst I have a couple of unnecessary calculations. Which I don't particularly like the idea of redundant code.

 

I may relook into it only for my own understanding, but are loath to change it in case it causes a "domino or house of cards effect"... so perhaps the old adage "If it ain't broke, don't fix it" should be adhered to?

 

Cheers.

 

 oops!  that was an embarrassing mistake - I'm glad you got it to work for you.

 

I may relook into it only for my own understanding, but are loath to change it in case it causes a "domino or house of cards effect"... so perhaps the old adage "If it ain't broke, don't fix it" should be adhered to?

I find that using a database analysis tool like Goya's BaseElements or Beezwaxes Inspector is the key to preventing an unexpected "domino effect". It allows you to search for all references to the field (provided you are not using indirection methods). You can also do this by using the DDR directly, but an analysis tool is much easier to use if you have to do it often.

That is really good!

Syntax is my main enemy - I have to check it it out properly.

 

Thanks for your input.