> > Did you consider String concatenation if the
> "time"
> > you have is nothing but yet another
> semicolon-divided
> > String?
>
> That really doesn't seem a very good idea.
It does to me though I would do it with String.replaceAll().
> > > Did you consider String concatenation if the
> > "time"
> > > you have is nothing but yet another
> > semicolon-divided
> > > String?
> >
> > That really doesn't seem a very good idea.
>
> It does to me though I would do it with
> String.replaceAll().
Would one of you care to explain why that would be a better solution then SimpleDateFormat?
Because (a) you're reinventing the wheel with all that that implies (b) some validation is provided free of charge with SimpleDateFormat
Anyway here are the codes.
import java.text.SimpleDateFormat;
public class Test{
public static void main(String[] args)throws Exception{
SimpleDateFormat in = new SimpleDateFormat("HH:mm");
SimpleDateFormat out = new SimpleDateFormat("H'hrs'mm'min'");
String[] tests = {"06:20","17:45","0:83"};
for(int i=0;i<tests.length;i++){
System.out.println(out.format(in.parse(tests[i])));
}
}
}
>
> > > > Did you consider String concatenation if the
> > > "time"
> > > > you have is nothing but yet another
> > > semicolon-divided
> > > > String?
> > >
> > > That really doesn't seem a very good idea.
> >
> > It does to me though I would do it with
> > String.replaceAll().
>
> Would one of you care to explain why that would be a
> better solution then SimpleDateFormat?
>
> Because (a) you're reinventing the wheel with all
> that that implies (b) some validation is provided
> free of charge with SimpleDateFormat
How does SDF cope with 72:20 ?
> > > > > Did you consider String concatenation if the
> > > > "time"
> > > > > you have is nothing but yet another
> > > > semicolon-divided
> > > > > String?
> > > >
> > > > That really doesn't seem a very good idea.
> > >
> > > It does to me though I would do it with
> > > String.replaceAll().
> >
> > Would one of you care to explain why that would be
> a
> > better solution then SimpleDateFormat?
> >
> > Because (a) you're reinventing the wheel with all
> > that that implies (b) some validation is provided
> > free of charge with SimpleDateFormat
>
> How does SDF cope with 72:20 ?
How would you like it to deal with it?
By default it rolls.
Or you can make it non lenient and have it blow up.
> > Would one of you care to explain why that would be
> a
> > better solution then SimpleDateFormat?
>
> The solution is the simplest that fits the current
> requirements, which is String manipulation.
How is that easier again then what I posted?
One less line of code?
> > Would one of you care to explain why that would be
> a
> > better solution then SimpleDateFormat?
>
> The solution is the simplest that fits the current
> requirements, which is String manipulation.
Agreed. SDF is proposed as the answer to ALL time and date formatting problems but it does not deal well with values outside the normal ranges (i.e. 63 minutes) and it distorts displays of time when dealing with a number of seconds or milliseconds that cross leap second and year boundaries.
> > > Would one of you care to explain why that would
> be
> > a
> > > better solution then SimpleDateFormat?
> >
> > The solution is the simplest that fits the current
> > requirements, which is String manipulation.
>
> Agreed. SDF is proposed as the answer to ALL time and
> date formatting problems but it does not deal well
> with values outside the normal ranges (i.e. 63
> minutes) and it distorts values of time when dealing
> with a number of seconds or milliseconds that cross
> leap second and year boundaries.
This is rubbish, SDF does no such thing. Calendar and date are doing that and while that may seem pedantic to you it seems a pretty important point to me.
We do not know what the requirements of the OP are really, and we are probably unlikely to know. There are several reasons, which I gave, as to why SDF is the solution to choose, in my opinion.
As to the points the two of you have made:
- the point about distortion is convoluted although maybe perhaps valid. but only valid if it violates the OP's requirements which we do not know
- the point about simple is rubbish
Regexes are not the answer to every problem in life or Java. Especially when a pre-existing, well tested, well understood later by other programmers looking at the code solution exists.
<snip>
> This is rubbish, SDF does no such thing. Calendar
> and date are doing that and while that may seem
> pedantic to you it seems a pretty important point to
> me.
Not rubbish! Not pedantic!
>
> We do not know what the requirements of the OP are
Agreed - which, unlike you, is why in my first post I did not propose a solution.
> really, and we are probably unlikely to know. There
> are several reasons, which I gave, as to why SDF is
> the solution to choose, in my opinion.
Your opinion.
>
> As to the points the two of you have made:
>
> - the point about distortion is convoluted although
> maybe perhaps valid. but only valid if it violates
> the OP's requirements which we do not know
> - the point about simple is rubbish
Not rubbish.
>
> Regexes are not the answer to every problem in life
> or Java.
Horses for courses. I proposed regex partly to offset the rush towards SDF though I could equally well have proposed a 'substring' approach.
> Especially when a pre-existing, well tested,
> well understood later by other programmers looking at
> the code solution exists.
I see more potential problems to the use of SDF than I do to using regex or substring.
> > As to the points the two of you have made:
> >
> > - the point about distortion is convoluted
> although
> > maybe perhaps valid. but only valid if it violates
> > the OP's requirements which we do not know
> > - the point about simple is rubbish
>
> Not rubbish.
Because why exactly?
> > Especially when a pre-existing, well tested,
> > well understood later by other programmers looking
> at
> > the code solution exists.
>
> I see more potential problems to the use of SDF than
> I do to using regex or substring.
That is primarily because you are biased towards regexes.
At any rate I am willing to concede about, as you phrased it, distortion, might be an issue in some cases. But the simplicty argument is rubbish, I'm sorry but it is.
> > > As to the points the two of you have made:
> > >
> > > - the point about distortion is convoluted
> > although
> > > maybe perhaps valid. but only valid if it
> violates
> > > the OP's requirements which we do not know
> > > - the point about simple is rubbish
> >
> > Not rubbish.
>
> Because why exactly?
As a counter - why do you say it is rubbish? Exactly what aspect of my earlier statements do you think is rubbish?
>
> > > Especially when a pre-existing, well tested,
> > > well understood later by other programmers
> looking
> > at
> > > the code solution exists.
> >
> > I see more potential problems to the use of SDF
> than
> > I do to using regex or substring.
>
> That is primarily because you are biased towards
> regexes.
No really true - I am biased towards regex for problems involving string manipulation. You view the OPs problem as date conversion problem, I view it as a string manipulation.
>
> At any rate I am willing to concede about, as you
> phrased it, distortion, might be an issue in some
> cases. But the simplicty argument is rubbish, I'm
> sorry but it is.
I'm not sure I understand this? The simplicity argument is primarily yours. I have to go out now to help someone move house but I will re-read the 'simplicty' arguments later and get back.