This week's book giveaway is in the Other Open Source APIs forum. We're giving away four copies of Storm Applied and have Sean Allen, Peter Pathirana & Matthew Jankowski on-line! See this thread for details.
I need to do some date comparisons so my plan is to simply convert dates to timestamps. However, I found what seems to be an inconsistency between Calendar and Date classes. I obtain today's time stamp thus:
For today (01/28/13) this gives me 1359483098370. I then convert a calendar date thus:
When I set thedate="02/09/13" the timestamp is 1357707720000. Since it is impossible for a date in the future to have a timestamp less than today I must be doing something wrong. Is my assumption that a 2 digit date defaults to the current century incorrect? If so then how so I set it to the current century without having to modify the format of the incoming (thedate) date variable? TIA.
Dennis Putnam wrote:How stupid is that? All it took was some new eyes. Thanks.
Often does. That's why God gave us the internet.
When I was in college (~1979), I did a lot of Fortran programming, initially all on punched cards. We got a time-sharing minicomputer before I left, though, so I switched from cards to a terminal (remember those?). One day, I was working on a program that opened and read a file. The "open" statement in that version of Fortran was pretty arcane, and took a potentially long list of parameters, each of which had to be named. If your Fortran statement ran too long, you could continue it on the next line, but you had to mark the line as a continuation of the one before it. I don't remember the exact Fortran, but my file-opening statement looked something like this:
My program worked fine. After a while, I had to add some fields to my record, so my open statement had to change to this:
My program compiled and still ran, but it only read the first few characters of each record. I worked on this for hours, finally realizing that my program "broke" whenever I had a record length of 100 or more characters. I was on the verge of concluding that the file i/o system had a bug, when another student walked in, looked over my shoulder, and said, "Your first line is too long." Too long? What he meant was that, in the days when programs were punched onto cards, the statements had to be in the first 72 columns because columns 73-80 were reserved for serial numbers. That was very useful if you dropped your deck of cards and had to sort them back into the original order, but we simply never did that.
Now, don't ask me why I put that comma in front of the word "STATUS." I just did, for some reason. The end result was that, in my first version, the compiler correctly saw my record length as "80." In my second version, the compiler saw my record length as "10," and my line containing the record length as having a serial number of "4" in the first of the eight reserved columns on the "card" the compiler still thought it was reading (even though I was using a whiz-bang, super-cool, can-I-have-one-for-Christmas-Mom? Digital Equipment Corporation VT-100, which didn't show the column labels like the cards did .) [Yes, the example above is nowhere near long enough for the problem I actually experienced, but I can't remember enough Fortran to fill it out that far.]
Today, over 30 years later, I am still not sure if I wanted to kiss him, or kill him, for pointing out my error.
Sometimes, this just ain't the right game for the weak, eh?
Joined: Feb 03, 2012
Ah yes, the good old days. I too started with Fortran IV on an IBM 1401. At least you didn't say you finally got your program working when the rubber band broke and you dropped your unnumbered deck on the floor. Not that it would have mattered, students did not have access to the card sorter. I guess we have dated ourselves.
Dennis Putnam wrote:Ah yes, the good old days. I too started with Fortran IV on an IBM 1401...
Oh dear. I suspect that makes you even older than me. I missed out on Autocoder on the 1401 by about 6 months.
However, to get back to your question: java.util.Calendar is only concerned with manipulating timestamps, or obtaining specific values from it according to some Locale; and I suspect is not even required in your case.
long now = System.getTimeInMillis();
is all you need to get the current date/time, and it'll be a lot quicker than creating a Calendar.
If you simply want to know if two timestamps are on the same date for a given Locale (very important), I'd suggest:and you could convert it to accept both times and java.util.Date's by making 't1' and 't2' Objects.
Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here