• Clockwork-muse (unregistered) in reply to Cbuttius
    Cbuttius:
    DateFormat / SimpleDateFormat has been part of Java for a long time and does of course address that situation, but you need to hold on to your DateFormat object as long as you need it.

    Unfortunately, SimpleDateFormat isn't threadsafe either, so it can't be cached in a threaded context either; this is because it stores the calendar passed for formatting (and possibly the string for parsing) and/or uses a member variable for output. The standard recommendation is to create a new instance every time you need one, otherwise you get strange output. This is one of the reasons I prefer JodaTime (and am looking forward to the new date/time API)

  • S (unregistered) in reply to faoileag
    faoileag:
    So I assume multiple calls to getInstance() will return references to different instances, although I couldn't find any clarification on that in the docs.

    There's no clarification because you're the first person I've seen who's ever thought that the method might be returning a singleton instance. The Java date APIs are crap (if thankfully improving in Java 8), but they're not so bad that they only allow you to use a single date in the system...

  • S (unregistered) in reply to Martijn
    Martijn:
    Joda/Noda works, but cumbersome - which is amazing enough apparently - and isn't a standard library. Other than that I wouldn't know.

    Java 8's new date/time API is strongly inspired by Joda (not identical, but very similar), so perhaps that will give you what you want.

  • S (unregistered) in reply to herby
    herby:
    Is it just me, or are 'long' variables limited to 32 bits.

    It's just you. A Java 'int' is 32-bit, but a 'long' is (and always has been) a 64-bit value.

  • Baboon (unregistered) in reply to Clockwork-muse
    Clockwork-muse:
    Cbuttius:
    DateFormat / SimpleDateFormat has been part of Java for a long time and does of course address that situation, but you need to hold on to your DateFormat object as long as you need it.

    Unfortunately, SimpleDateFormat isn't threadsafe either, so it can't be cached in a threaded context either; this is because it stores the calendar passed for formatting (and possibly the string for parsing) and/or uses a member variable for output. The standard recommendation is to create a new instance every time you need one, otherwise you get strange output. This is one of the reasons I prefer JodaTime (and am looking forward to the new date/time API)

    You could pool them, the safety guarantee is only around concurrent access ... if you make the operations atomic, you will NEVER get a mangled date ...

    However +1 to the new date/time API and I also agree Joda time is far superior.

  • faoileag (unregistered) in reply to S
    S:
    faoileag:
    So I assume multiple calls to getInstance() will return references to different instances, although I couldn't find any clarification on that in the docs.

    There's no clarification because you're the first person I've seen who's ever thought that the method might be returning a singleton instance.

    Sorry, didn't think :-) And I should have read more of the documentation, the constructors are protected, so getInstance() is the only way to get an instance.

  • anonymous (unregistered)

    Nobody has noticed this yet?

    The resulting date format is not yyyyMMddhhmmss

    It is yyyyMMddhhmmssSSS

    where SSS is the number of milliseconds (i.e. currtime % 1000L)

    Also, there is not an off-by-1 error, because Calendar.MONTH returns a month that is zero-based. January is month 0, so adding 1 is correct.

  • Done Right (unregistered) in reply to anonymous
    anonymous:
    Nobody has noticed this yet?

    The resulting date format is not yyyyMMddhhmmss

    It is yyyyMMddhhmmssSSS

    You mean: yyyyMMddHHmmssSSS

    And why not include the timezone: yyyyMMddHHmmssSSSZ

  • (cs) in reply to Done Right
    Done Right:
    anonymous:
    Nobody has noticed this yet?

    The resulting date format is not yyyyMMddhhmmss

    It is yyyyMMddhhmmssSSS

    You mean: yyyyMMddHHmmssSSS

    And why not include the timezone: yyyyMMddHHmmssSSSZ

    Yeah. I was mainly noticing that it included milliseconds and the article didn't; it didn't occur to me that the remainder of the format string might be wrong too.

    Why not include the timezone? Because the timezone can't be expressed in a number from 0 to 9, of course.

  • (cs)
    the decimal number of milliseconds since the dawn of Unix Time
    I see the real WTF: This code fails to account for the milliseconds it takes to format the date into a string!
  • (cs) in reply to Done Right
    Done Right:
    anonymous:
    Nobody has noticed this yet?

    The resulting date format is not yyyyMMddhhmmss

    It is yyyyMMddhhmmssSSS

    You mean: yyyyMMddHHmmssSSS

    And why not include the timezone: yyyyMMddHHmmssSSSZ

    Shouldn't that be: yyyyMMddHHmmSSsssZ ? Or is it: YYYYmmDDhhMMssSSSz ? Damn, dates are hard.
  • Ol' Bob (unregistered) in reply to Severity One
    Severity One:
    Bobby Tables:
    faoileag:
    no laughing matter:
    Actually it indicates that even one user at the same time can be troublesome.

    MySQL, MySpace, My Verizon, My Little Pony.

    In the case of MySQL that would be Bobby, wouldn't it?
    I think that's very inconsiderate for all Bobbys across the world.
    I had a son once that was Bobby, and let me tell you, it was no laughing matter.

    Parents can be so difficult...

  • Hannes (unregistered)

    Seems that DateTimes confuse the hell out of people. Here's something I found in one of the programs at my workplace:

    string dateminus; int convertus = 0; string dateminus2; int convertus2 = 0; int emeil1 = 0, emeil2 = 0;
string eMailText = ""; string reminderText = "";
for (int i = 0; i <= this.RM._B_S.Count; i++)
{
  try
  {
    emeil1 = 0;

    if (this.RM._B_S[i].Reminder_Deadline.ToString("dd.MM.yyyy") != DateTime.Now.ToString("dd.MM.yyyy"))
    {
      dateminus = this.RM._B_S[i].Reminder_Deadline.ToString("dd.MM.yyyy");
      convertus = Convert.ToInt16(dateminus.Substring(0, 2));
      dateminus2 = DateTime.Now.ToString("dd.MM.yyyy");
      convertus2 = Convert.ToInt16(dateminus2.Substring(0, 2));

      if ((convertus == convertus2) || (convertus - 1 == convertus2) || (convertus - 2 == convertus2) || (convertus - 3 == convertus2))
      {
        convertus = Convert.ToInt16(dateminus.Substring(3, 2));
        convertus2 = Convert.ToInt16(dateminus2.Substring(3, 2));

        if (convertus == convertus2)
        {
          convertus = Convert.ToInt16(dateminus.Substring(6, 4));
          convertus2 = Convert.ToInt16(dateminus2.Substring(6, 4));

          if (convertus == convertus2)
          {
            //do some stuff...
            if (emeil1 != 1)
            {
              //do other stuff....
            }
          }
        }
      }
    }
  }
  catch
  {
  }
}

    Yes. It is really converting the Day of the date to int to check, if date1 was three/two/one days prior to date2. And yes again, it really does the same thing for the months again.

  • Neil (unregistered) in reply to S
    S:
    faoileag:
    So I assume multiple calls to getInstance() will return references to different instances, although I couldn't find any clarification on that in the docs.
    There's no clarification because you're the first person I've seen who's ever thought that the method might be returning a singleton instance.
    Being unfamiliar with the Java Date API (not having used it since doing a bit of Java 1.1 JDBC) I would have looked for a createInstance() factory method if I wanted to, well, create a new instance each time; getInstance() would just get the same instance as last time. (Of course for instance methods such as getParent() there is the possibility that the object has been mutated between the calls in which case the return value would change.)

Leave a comment on “Date Formatting Done Right”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article