× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.





I like my solution better. What happens if the duration exceeds an hour?

If the duration exceeds an hour? HUH? Why would it matter if the duration exceeded an hour? The whole point of dividing by 60 was to get the number of hours.


The problem with your solution is that a time data type is designed to hold the time of day, NOT a duration.

If you had a duration of 14 hours and 20 minutes, and you stored it in a TIME operation, then displayed it with *USA format, it would show as 2:20 PM instead of 14 hours. (Of course, you can easily avoid this by hard-coding the time format)

However, if your "number of hours" field exceeds 24 hours, kaboom, your program will blow up. A time field cannot store a value higher than 23:59:59 because, again, it's designed to represent a time of day, not a duration. (Of course, if you know ahead of time that it'll never be that high, you could still use your method.)

If you switch it to use a timestamp instead of a time field, you'd eliminate the 24 hour problem, but then it would show a year value that would inevitably be wrong. Plus it would do odd things like handle leap years and other things that you don't want when you're expressing a duration rather than a specific point in time.

My solution would never have these problems.

For example, our company makes sausage. When fresh (uncooked) sausage comes out of the department where it's stuffed and packaged, it needs to go into a blast freezer to freeze it solid. It has to remain in that blast freezer for around 100 hours.

So, I have a database record that contains the time that the product went into the freezer. They have a screen to view, at any given moment, how long the sausage has been in the freezer.

If I used your solution, it would never work. I'd either have to show them a duration under 24 hours, or I'd have to show them 0001-01-03-00:05:06.000000 (or something like that) which really wouldn't help them determine how long the product had been in there.

Using my solution, I can do this:

     C     CurrentTime   subdur    TimePutIn     mins:*mn
     C                   eval      hoursin  = %div(mins: 60)
     C                   eval      minsin   = %rem(mins: 60)
     C                   eval      duration = %editc(hoursin:'Z') + ':'
                                            + %editc(minsin:'X')

Assuming that 'hoursin' is at least 3,0, I have no problem showing 100 hours or more on the screen. When they see it on the screen, it shows something like ' 99:45' and they say "cool, I can take that one out in 15 minutes".

I've used solutions like yours in the past. I've even posted them here as suggestions. But whenever I've done something like that in a production program, it always came back to bite me. There's always some obscure "exception to the rule" where they had more than 24 hours on something, and the program crashes with a date/time/timestamp error.

And the user has NO CLUE whats going on when that happens. No matter what you say, he just can't understand why the program didn't work.

And, all that to save me, what? Two lines of code? maybe 45 seconds of typing?


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.