• Anonymouse (unregistered) in reply to Leak
    Leak:
    08.30.07 - Never forget!

    Hey, asshole, it's not August 2007.

  • mathew (unregistered)

    If Java's date API wasn't such a clusterfuck in itself, maybe people wouldn't do this kind of shit.

  • (cs) in reply to Not american
    Not american:
    The other commenter neglected Canada which can be considered practically USA, the Philippines and the unforgettable illustrious Republic of Palau as well as the Federated States of Micronesia.
    Except that this isn't about countries that specifically use mm/dd/yyyy format, it's about countries that don't use dd/mm/yyyy.

    So you might also want to include just about all of Asia, South Africa, the entire middle east, and several parts of Europe that all use the ISO standard yyyy-mm-dd.

    So yes, it really is effectively "UK/Europe" format, and most certainly isn't "Everywhere-that-isn't-USA" format.

  • Pragmatist (unregistered) in reply to mathew
    mathew:
    If Java's date API wasn't such a clusterfuck in itself, maybe people wouldn't do this kind of shit.

    Maybe you can make a better one and release it under the GPL.

  • (cs)

    Why use anything else then C or Assembler?

  • (cs) in reply to Yankee Doodle
    Yankee Doodle:
    Wait a second. As a lifelong American, I'm under the impression that pretty much everywhere is part of the USA.

    How right you are, you just forgot to mention the earth is flat.

  • Contractor Khan (unregistered) in reply to mathew
    mathew:
    If Java's date API wasn't such a clusterfuck in itself, maybe people wouldn't do this kind of shit.

    It's not java - that is the reason no one is listening to the anti-java crowd - you bitch before you think and you are too quick to show what you don't know.

  • Ken Sykora (unregistered)

    This is the best part of this WTF:

    catch(Exception)
    {
        return 3;
    }
    
  • Todd (unregistered)

    I once watched a coworker scratch his head over his sometimes failing date functions. January through July worked fine, August and September would fail outright, and October through December were just wrong.

    He was new to C and didn't appreciate the difference between integer conversion and decimal conversion. Just so you know, the string "08" is an invalid (implied) octal for integer conversions, but it's perfectly fine for decimal conversions with its harmless leading zero.

    I laughed 'till he cried, then clued him in. Fun times. Fun times.

  • Jonah (unregistered)
    try { ... } catch(Exception) { return 3; }
    A new design pattern is born! From now on, I'm going to use this in all my functions.
  • (cs) in reply to Aaron
    Aaron:
    Not american:
    The other commenter neglected Canada which can be considered practically USA, the Philippines and the unforgettable illustrious Republic of Palau as well as the Federated States of Micronesia.
    Except that this isn't about countries that specifically use mm/dd/yyyy format, it's about countries that don't use dd/mm/yyyy.

    So you might also want to include just about all of Asia, South Africa, the entire middle east, and several parts of Europe that all use the ISO standard yyyy-mm-dd.

    So yes, it really is effectively "UK/Europe" format, and most certainly isn't "Everywhere-that-isn't-USA" format.

    so the whole of south america, the asian sub-continent and australia now form part of uk/europe? interesting.

  • (cs) in reply to Yankee Doodle
    Yankee Doodle:
    Wait a second. As a lifelong American, I'm under the impression that pretty much everywhere is part of the USA. I mean, didn't one of our presidential candidates just make campaign stops in the states of Afghanistan and Germany?

    And when they show the weather maps on Tee Vee (AKA Web 0.0) the USA covers about 3/4 of the globe, except for that little tail that heads off toward Mexico or whatever those other places are called.

    Stop reinforcing the stereotype of Americans being ignorant of the rest of the world.

    Germany and Afghanistan are US Territories, not states. We liberated them in WWII, but never granted them statehood. They have a similar status to the UK (Liberated in the Revolutionary War) and Russia (Liberated in the Cold War).

  • fa_f3_20 (unregistered)

    What is it anyway with the compulsion some people seem to have now with wanting to handle all data as strings?

  • Contractor Khan (unregistered) in reply to fa_f3_20
    fa_f3_20:
    What is it anyway with the compulsion some people seem to have now with wanting to handle all data as strings?

    I blame Python.

    In other languages, someone who gets paid $20 an hour (arguments sake) and works for 10 hours gets: 20 * 10: $200.

    In Python however, if you treat "20" as a String: "20" * 10: $20202020202020202020

    A much better wage!

  • (cs)

    You are TheLesserDate. Goodbye.

  • Chucara (unregistered)

    I love how he multiplies the year by 10000 and the month by 100. While it will actually produce the correct result, it isn't especially intuitive. Gets around those pesky leap years though.

  • (cs) in reply to A Nonny Mouse
    A Nonny Mouse:
    Aaron:
    Not american:
    The other commenter neglected Canada which can be considered practically USA, the Philippines and the unforgettable illustrious Republic of Palau as well as the Federated States of Micronesia.
    Except that this isn't about countries that specifically use mm/dd/yyyy format, it's about countries that don't use dd/mm/yyyy.

    So you might also want to include just about all of Asia, South Africa, the entire middle east, and several parts of Europe that all use the ISO standard yyyy-mm-dd.

    So yes, it really is effectively "UK/Europe" format, and most certainly isn't "Everywhere-that-isn't-USA" format.

    so the whole of south america, the asian sub-continent and australia now form part of uk/europe? interesting.
    North America, too. Mexico uses dd/MM/yyyy format. ;)

    However, I've switched mostly to the ISO-8601 standard, for most of the reasons stated above. In fact, some apps actually use a bastardized version of the ISO 8601 format:

    yyyyMMdd (we don't need no steeeenkin' delimiterz!)

    Oh, what fun. Anyway, isn't this function just doing what this can do?

    Date firstDate = new SimpleDateFormat("dd/MM/yyyy").parse(stringDate);

    (or something like that.)

  • Contractor Khan (unregistered) in reply to danixdefcon5
    danixdefcon5:
    snip Date firstDate = new SimpleDateFormat("dd/MM/yyyy").parse(stringDate);

    (or something like that.)

    It would make more sense if his method REQUIRED date objects - that way it only needed to check if they were null as the framework should make sure they are valid date objects otherwise.

    Then parsing doesn't need to be done by the method - parsing can be done by whatever needs the comparison done, as long as it can form a valid date from it's data.

  • Frank B (unregistered) in reply to Volmarias

    Actually, you can't compare date strings using string comparison, unless you can guarantee that single-digit day or month values won't happen. Because then "5/12/2008" would be greater than "18/12/2008". So that is the reason for this (not very elegant, but correct) code. No WTF here.

  • Rhywun (unregistered) in reply to Not american
    Not american:
    K&T:
    Just FYI, it's not called UK/Europe format, it's called Everywhere-That-Isn't-USA format. So technically there's nothing wrong with it. TRWTF is Month/Day/Year.

    FYI, you're wrong

    The other commenter neglected Canada which can be considered practically USA, the Philippines and the unforgettable illustrious Republic of Palau as well as the Federated States of Micronesia.

    Don't ever forget about them!

    Or a little place called China (yyyy/mm/dd).

  • (cs) in reply to fa_f3_20
    fa_f3_20:
    What is it anyway with the compulsion some people seem to have now with wanting to handle all data as strings?
    Three Letters: XML

    All data is strings...

  • Crazy Taco (unregistered) in reply to NThenUDie
    The real WTF is he's returning an int instead of the correct return enum value for comparison operators

    And it's not even a regular int, it's a short! He probably thought he was being 1337 with this code since he even saved memory space, when in reality this is stupid.

  • (cs) in reply to Chucara
    Chucara:
    I love how he multiplies the year by 10000 and the month by 100. While it will actually produce the correct result, it isn't especially intuitive. Gets around those pesky leap years though.
    Not really, a lot of people who can't be bothered to use proper dates (or, to be fair, who have to move data between a variety of database systems with incompatible date formats) do basically the same thing. I inherited a system in my new job where all the data is analysed in SPSS before being DTSed into SQL Server. SPSS not only lacks compatible date formats (hence all dates are stored as integers of the type 20080401) but also any equivalent of varchar, so most of the string data is padded to 255 chars with spaces. The data analysis team are currently planning a silent revolution aimed at ridding the organisation of SPSS once and for all...
  • Charles (unregistered)

    Oh man. We are such losers. We can't even handle dates in code, much less get a date for dinner and movie.

    Captcha: vereor - A new type of meteor.

  • lord (unregistered) in reply to pscs

    No the 100days in a month and 10000 months in a year is just a form of left shift by powers of 10 so today would be represented as a number 20,080,730 so you can compare them without losing information.

  • (cs)

    Germany: dd.mm.yyyy

    Just to point out that you can't rely on the / either.

  • Mike (unregistered)

    It even returns a short. How cute. At least he's not wasting memory...

  • lord (unregistered) in reply to lord

    "No the 100days in a month and 10000 months in a year is just a form of left shift by powers of 10 so today would be represented as a number 20,080,730 so you can compare them without losing information."

    I've unfortunately had to use this as a sort criteria in SQL as I could not find a way to get SQL to ignore the timestamp portion of the date when sorting.

  • 0 Jan (unregistered)

    On the brighter side, it appears to handle those fictive dates governments sometimes require apps to use, like 0-Jan-nn, 32-Dec-nn (sometimes even 33 and 34) 01-(Dec+1)-nn and 31-(Dec-1)-nn. (These do exist in government accounting systems)

    Whereas a well-educated Date type won't work. Maybe that contractor wasn't so silly.

  • MTS (unregistered)

    What happens to Jared when he does something simple like "if ('12/31/2007' < '01/01/2008')"?

  • annonymous (unregistered) in reply to Chucara
    Chucara:
    I love how he multiplies the year by 10000 and the month by 100. While it will actually produce the correct result, it isn't especially intuitive. Gets around those pesky leap years though.
    lord:
    No the 100days in a month and 10000 months in a year is just a form of left shift by powers of 10 so today would be represented as a number 20,080,730 so you can compare them without losing information.

    I'd say he picked 10000 and 100 so that when printed it looks like yyyyMMdd, look at the above example without the commas: 20080730

  • (cs)

    Heh. I read this and at first thought, "Dang, this Jared guy is REALLY shallow. The real WTF is that he is comparing two people using code."

  • Dan (unregistered) in reply to NThenUDie

    I think you made a typo..

    enum LessThanReturnCodes {Unknown, Lesser, GreaterOrEqual, FileNotFound, Maybe, Probably, ImFeelingLucky, ...}

    -Dan

  • pytechd (unregistered) in reply to Sunday Ironfoot

    The real WTF is comparing dates based on strings. String-based dates are an initial or final representation of a date only -- internally, all dates should be date-type objects (locale, time zone, etc agnostic).

  • (cs) in reply to NThenUDie
    NThenUDie:
    The real WTF is he's returning an int instead of the correct return enum value for comparison operators

    enum LessThanReturnCodes {Unknown, Lesser, GreaterOrEqual, FileNotFound}

    What's the difference between Unknown and FileNotFound? I always imagined FileNotFound is returned if you try, say, TheLesserDate("fish", "chips"), so what causes Unknown? TheLesserDate("fish", "girlfriend")?

  • (cs) in reply to JimM
    JimM:
    What is it anyway with the compulsion some people seem to have now with wanting to handle all data as strings?
    Actually, I suspect that close to 90% of all programmers don't properly understand that bytes are bytes and strings are strings and you should avoid converting between them unless actually necessary and then only by carefully considering which encoding to use.

    I've seen quite a number of experienced and otherwise competent programmers do really stupid crap that begins with the thought, "What to do with this data? Well, let's first turn it into a string..."

    fa_f3_20:
    Three Letters: XML

    All data is strings...

    <?xml version="1.0" encoding="it-bloody-well-aint"?>

    Just yesterday I had to fix some backend Java code that had two setXmlData() methods, one accepting Strings, the other byte arrays. The byte array one took the raw data, converted it to String using a hardcoded (i.e. possibly wrong) encoding, then passed it to the other method, which converted it back to bytes using the same hardcoded encoding, passed those into an InputStreamReader which used the platform default encoding (i.e. a possibly different and also wrong one) to turn them into a character stream to feed into the XML parser ... which was perfectly capable of not only accepting raw bytes but also of analyzing them to find the actually correct encoding in the XML header...

    I probably should submit that code here.

  • m.vincenttis (unregistered)

    Wow! What a kind the language is that? I guess it's not Java.

    Well, take a look this. As long as its result is int: -1 lesser, 0 equal, 1 greater, no problem with this, that is java old times without Enums. Taking a deep look you'll see the Date objects are completely wrong. Despite that, the comparising works!.

    package org.abstra;

    import java.text.ParseException; import java.text.SimpleDateFormat; import java.util.Date; import java.util.GregorianCalendar;

    public class Tester1 { /** * Format: MM/dd/yyyy * @param dateFrom * @param dateTo * @return -1 lesser, 0 equals, 1 greater * @throws ParseException */ public int getLesserDate(String dateFrom, String dateTo){ SimpleDateFormat sdf = new SimpleDateFormat("MM/dd/yyyy");

    	GregorianCalendar gcDateFrom = new GregorianCalendar();
    	GregorianCalendar gcDateTo =   new GregorianCalendar();
    	
    	try {
    		Date dtFrom = sdf.parse(dateFrom);
    		Date dtTo   = sdf.parse(dateTo);
    		gcDateFrom.setTime(dtFrom);
    		gcDateTo.setTime(dtTo);
    
    	} catch (ParseException e) {
    		e.printStackTrace();
    	}
    	
    	return gcDateFrom.compareTo(gcDateTo);
    }
    
    public static void main(String[] args) throws ParseException {
    	Tester1 t1 = new Tester1();
    	
    	String dtFrom = "99/99/2007";
    	String dtTo   = "99/99/2008";
    	System.out.println(t1.getLesserDate(dtFrom, dtTo));
    }
    

    }

  • (cs) in reply to m.vincenttis
    m.vincenttis:
    Well, take a look this. As long as its result is int: -1 lesser, 0 equal, 1 greater, no problem with this, that is java old times without Enums. Taking a deep look you'll see the Date objects are completely wrong. Despite that, the comparising works!.

    From the API:

    public void setLenient(boolean lenient)

    Specifies whether or not date/time interpretation is to be lenient. With lenient interpretation, a date such as "February 942, 1996" will be treated as being equivalent to the 941st day after February 1, 1996. With strict (non-lenient) interpretation, such dates will cause an exception to be thrown. The default is lenient.
    
  • davo (unregistered) in reply to pscs
    pscs:
    Apart from the name of the function, it doesn't look too bad if you know you are getting the dates in as dd/mm/yyyy strings, and you don't need to validate them.

    You can't just test for something like (DateFrom < DateTo), as they're strings.

    The alternative would be to use a date parser, but doing something like (IANAJPSPFMFAM):

    Date from = new SimpleDateFormat("dd/MM/yyyy".parse(DateFrom); Date to = new SimpleDateFormat("dd/MM/yyyy".parse(DateTo); if (from < to) then

    is harder to read/write than if (CompareDate(DateFrom, DateTo) == 1)

    His "quick & nasty" parser is also probably going to be quicker to execute as well.

    Maybe it could be improved by using enums or -1, 0, 1 for the return value.

    Nah... 0, 1, 2, and 3 are the most logical return values ever!!!

  • Per "md2perpe" Persson (unregistered)

    The way we write dates in Sweden is so great: yyyy-mm-dd. It's just to compare them as strings.

  • Machine Head (unregistered) in reply to Sunday Ironfoot
    Sunday Ironfoot:
    a) Make sure locale settings on the deployment server at set to UK/Europe b) Make sure other developers who use this code pass in a string date in UK/EU format.
    It's UK-Format. Other regions use other date formats.
  • Machine Head (unregistered) in reply to pscs
    pscs:
    -1, 0, 1
    Balanced Terniary rulez!

    See: http://en.wikipedia.org/wiki/Balanced_ternary

  • 008 (unregistered)

    You only have one byte of memory left to return the result. Now what?

  • Dave G. (unregistered) in reply to TGV

    I like how he redefines delim, just incase a buffer overrun in another unrelated part of the application just happened to trash that particular location in memory in the time between its initial declaration and its second use. His code is impervious to such trivialities!

    I'm glad some developers have a clue about writing secure code.

  • gravis (unregistered)

    I love that "on exception, ummm, return 3"

    :D

  • PhysicsPhil (unregistered) in reply to JimM
    JimM:
    fa_f3_20:
    What is it anyway with the compulsion some people seem to have now with wanting to handle all data as strings?
    Three Letters: XML

    All data is strings...

    No it isn't: CDATA is anything you want.

    I think it comes from people not understanding the Unix principle that all data should be transferred as strings, and think that is is best to handle them internally as stings as well.

  • Alexander (unregistered)

    Actually I'm working on several data migration projects where dates are coming from dubious sources (varchars in the database, Excel columns with arbitrary formatting, ...). And this is Germany, so you have a wild mixture of German, UK and US dates (and probably some French as well). I think I'm above 70 different patterns now with my rather heuristic date guessing function. So if somebody want's to review some real fun code...

  • Alexander (unregistered) in reply to Jonah

    This is wrong! It should always be:

    try
    {
    ...
    }
    catch(Exception)
    {
    return 42;
    }
    
  • WasteOfSpace (unregistered)

    Excellent! I always wanted something more impressive than .CompareTo to do this job.

  • (cs) in reply to pscs
    pscs:
    A reasonable way to do it is either to use a proper (probably inefficient) date parser with idiosyncratic interface [WHAT???](which date parsers usually have), or do something similar to the way he's done it.

    (Maybe people are complaining about the "100 days in a month and 10000 days in a year" design decision, but to avoid unnecessary complexity you want a number >=31 for the days in the month, and >=366 for days in a year, and using 100/10000 (a) makes it clear you haven't actually got the number of days since an arbitrary point in time, and (b) makes debugging a lot easier, and won't cause any overflow problems for a couple of hundred thousand years).

    WHAT???

Leave a comment on “The Lesser Date”

Log In or post as a guest

Replying to comment #:

« Return to Article