• (cs) in reply to Spencer
    Spencer:
    TRWTF is of course Java. How do you get the year from a Java Date object? 
    getYear()
    of course...except that the docs say this method has been deprecated as of JDK v1.1 (not only that, but it returns the year minus 1900)

    Java's Calendar class seems a little better, actually having a YEAR field (in amongst the absolute mess of fields it has), but it's an abstract class requiring specific implementations to use for each culture.

    Yeah, I'll stick with .NET where DateTime has a Year property (or if I'm stuck with Java for some reason, the Joda library)

    Even Python is better than that. Then again, I do think that Python is better than Java.

  • (cs) in reply to Charles U. Farley
    Charles U. Farley:
    What I really like about Mick's database table is the update timestamp. All that data looks like it was entered in using CTRL-C, CTRL-V

    Or defaulted to GETDATE(), then manually entered.

  • Bill C. (unregistered)
    snoofle:
    We've all heard of dates. Not the kind with someone to whom you're attracted.
    Lucky I'm not a programmer.
    Shane found a Yes table which has no counterpart No table... It has one row with one column containing a single "Y"... [image]
    Obviously Shane's ex-colleague wasn't a programmer either. He's heard of real dates, not the kind to which programmers are attracted.
  • (cs) in reply to herby
    herby:
    Then you need a database of leap seconds.
    No, you just need to know the difference between civil time and scientific time. In civil time, days are always exactly 86400 seconds long (ignoring timezone changes) and never has true leap seconds, whereas in scientific time, seconds are always exactly the same length forcing the use of leap seconds (at hard to predict intervals; the effects that cause the variability in the rate of earth's rotation are myriad).

    Most applications need civil time, and that's what the Unix epoch system uses; the quality of most local time sources is poor enough that the loss of accuracy is no big deal. The applications that need precise scientific time include things like GPS, but are really much less common.

  • Tux "Tuxedo" Penguin (unregistered) in reply to PlutoPlanet
    PlutoPlanet:
    Once I fixed PHP based CMS, where each page had its own table. And of course: All columns were of type TEXT. This was real fun...

    And what is exactly wrong with TEXT? Unless it is used for something weird like IDs or dates, where other types would be more appropriate, it is actually good way to store posts/titles without worrying that too long title/post will be cut in db.

  • sinni800 (unregistered)

    TRWTF is that every year-entry in the table took several seconds to create.

  • Vinit (unregistered)

    Didn't see the ID10T column anywhere...

  • anonymous (unregistered) in reply to Tux "Tuxedo" Penguin
    Tux "Tuxedo" Penguin:
    PlutoPlanet:
    Once I fixed PHP based CMS, where each page had its own table. And of course: All columns were of type TEXT. This was real fun...

    And what is exactly wrong with TEXT? Unless it is used for something weird like IDs or dates, where other types would be more appropriate, it is actually good way to store posts/titles without worrying that too long title/post will be cut in db.

    Maybe you should re-read this. "All columns" means yes, including columns like IDs and dates.

  • (cs) in reply to cyborg
    cyborg:
    Bobby Tables:
    Anonymous:
    Of course there is no "No" table. The non-existence of that table signifies the boolean value "False".

    I thought it signified the boolean FILE_NOT_FOUND.

    That is defined by a table that doesn't exist.

    OK, let's try this:
    SELECT 1 FROM FILE_NOT_FOUND

    ORACLE:

    ORA-00942: table or view does not exist
    Correct, but boring!

    MS-SQL:

    Invalid object name 'FILE_NOT_FOUND'.
    Slightly misleading. And it appears MS_SQL is an object-oriented database?

    Sybase:

    FILE_NOT_FOUND not found.
    My favorite!
  • (cs) in reply to Zylon
    Zylon:
    chubertdev:
    Do real developers double-click the Submit button on a web form?
    Real developers don't respond to Nagesh.

    TRWTF is Zylon!

  • (cs) in reply to Jaime
    Jaime:
    Real programmers don't open the can of worms that is storing dates. Calculating the numbers of milliseconds from the UNIX epoch given the local time and time zone is likely a harder problem than whatever program you're writing. You would have to worry about things like the fact that Samoa skipped Friday, December 31st, 2011.

    Actually, it was Friday, December 30th, 2011.

    Sincerely,

    Gene Wirchenko

  • Barf 4Eva (unregistered)

    Oh that's nothing. We have a database where almost all the tables have columns named identity, which are auto-incrementing numeric values, which is clustered on, and...

    are all varchar(50).

    oh the pain...

  • Fake' Nagesh (unregistered) in reply to Gene Wirchenko
    Gene Wirchenko:
    Jaime:
    Real programmers don't open the can of worms that is storing dates. Calculating the numbers of milliseconds from the UNIX epoch given the local time and time zone is likely a harder problem than whatever program you're writing. You would have to worry about things like the fact that Samoa skipped Friday, December 31st, 2011.

    Actually, it was Friday, December 30th, 2011.

    Sincerely,

    Gene Wirchenko

    And how exactly is storing dates in numbers going to solve this?

    I AM FAILINGS TO UNDERSTAND THIS, BOYZ.

  • (cs) in reply to Tux "Tuxedo" Penguin
    Tux "Tuxedo" Penguin:
    PlutoPlanet:
    Once I fixed PHP based CMS, where each page had its own table. And of course: All columns were of type TEXT. This was real fun...

    And what is exactly wrong with TEXT? Unless it is used for something weird like IDs or dates, where other types would be more appropriate, it is actually good way to store posts/titles without worrying that too long title/post will be cut in db.

    Cue DBA flamewar about TEXT vs VARCHAR.

  • (cs)

    Imitation is best form of flatter me.

  • (cs) in reply to chubertdev
    chubertdev:
    Tux "Tuxedo" Penguin:
    PlutoPlanet:
    Once I fixed PHP based CMS, where each page had its own table. And of course: All columns were of type TEXT. This was real fun...

    And what is exactly wrong with TEXT? Unless it is used for something weird like IDs or dates, where other types would be more appropriate, it is actually good way to store posts/titles without worrying that too long title/post will be cut in db.

    Cue DBA flamewar about TEXT vs VARCHAR.

    I always use VARCHAR2 in Oracle and NVARCHAR in SQL Server. If I can make it fit in VARCHAR2 / NVARCHAR, then TEXT column is not required. As a matter of fact, anything that is not fitting inside of VARCHAR2 / NVARCHAR column size is something you're definitely doing wrong.

    So Don't do it wrong. Do it right every time.

  • Bad Memories (unregistered)

    I wonder if any of the developers responsible for todays' entries worked at a certain big bank in America around 1999?

    My bundle of joy I had to baby was a carefully crafted Y2K database system the bank was using to inventory all their systems, software and hardware for testing and confirming Y2K compliance.

    OK, it was somewhat normalized, so beats out some of the entries here. But OMG, the field names, the field names! Each field name was a lengthy full sentence description including spaces and all punctuation. That's without getting into the little fact that the database system itself wasn't Y2K compliant. I was so happy when the project ownership changed to a far away office so I finally had an excuse to bail. (Too long a commute.)

  • Z (unregistered)

    My first gig out of college, in the previous millenium it was, at a five-man dotcom-bubble startup (counting the CEO and sole owner, and I use the word "man" intentionally, there being no female employees whatsoever), I don't remember why exactly but our software needed to convert Unix time_t values (i.e. counts of seconds since 1970-01-01T00:00:00Z) to "broken-down" time, and we couldn't rely on the C library for some damn reason which also escapes me now.

    The CEO-and-sole-owner had, before hiring me, implemented the algorithmically nastiest part of this task -- deciding what year the count was in -- using a table, hardwired into the executable, of time_t values for the start of every year from 1970 through 2038.

    Being a snotty kid fresh out of college, I filed a bug in the internal defect tracker: "this will break in 2038." The CEO-and-sole-owner responded by officially assigning the bug to his son. Who was six months old at the time.

    I don't think the company, or the product, still exists, but if it does, I'm sure that table is still there.

  • Norman Diamond (unregistered) in reply to Z
    Z:
    a five-man dotcom-bubble startup
    You mean five-and-a-half-men?
    Z:
    I don't remember why exactly but our software needed to convert Unix time_t values (i.e. counts of seconds since 1970-01-01T00:00:00Z) to "broken-down" time, and we couldn't rely on the C library for some damn reason which also escapes me now.
    Maybe the library handled UTC but some other code (GPS or some other requirement) handled GMT, or vice-versa?
    Z:
    The CEO-and-sole-owner had, before hiring me, implemented the algorithmically nastiest part of this task -- deciding what year the count was in -- using a table, hardwired into the executable, of time_t values for the start of every year from 1970 through 2038.
    Yes, that makes it sound like leap seconds were involved. Otherwise a constant offset from GMT or UTC could be computed from the time zone that was in effect on or near 1970-01-01, and each year would be 31536000 seconds long, except for leap years, and except for when DST rules change to have DST all year round or not, or half of a country changes from UTC+7.5 to UTC+8 ... Hmm, maybe a table is best anyway.
    Z:
    Being a snotty kid fresh out of college, I filed a bug in the internal defect tracker: "this will break in 2038." The CEO-and-sole-owner responded by officially assigning the bug to his son. Who was six months old at the time.
    It's nice to hear of a competent CEO. Nonetheless, you're lucky he didn't assign the bug to you.
  • Carrie (unregistered) in reply to Bad Memories
    Bad Memories:
    a carefully crafted Y2K database system the bank was using to inventory all their systems, software and hardware for testing and confirming Y2K compliance ... the database system itself wasn't Y2K compliant.

    Deadline enforcement, obviously. If you don't get the Y2K compliance finished by Y2K, the entire project crashes and burns.

  • nisl (unregistered) in reply to chubertdev
    chubertdev:
    Cue DBA flamewar about TEXT vs VARCHAR.
    Cue shuddering at the thought of nasty horrible DBMSes where there's a tangible difference between the two.
  • radarbob (unregistered) in reply to Dave
    Dave:
    Obviously the real WTF is the superfluous apostrophe in "it's", and the fact that none of you "geniuses" noticed it.

    It's :-} not superfluous, it's correct. In fact the apostrophe in "It[']s" is never superfluous. With the apostrophe it is a contraction of "it is". Without, it's the possessive.

  • anonymous (unregistered) in reply to radarbob
    radarbob:
    Dave:
    Obviously the real WTF is the superfluous apostrophe in "it's", and the fact that none of you "geniuses" noticed it.

    It's :-} not superfluous, it's correct. In fact the apostrophe in "It[']s" is never superfluous. With the apostrophe it is a contraction of "it is". Without, it's the possessive.

    It's not correct. It was the possessive of "it". The possessive of "it" is "its", without an apostrophe. "Superfluous" is not really the right word, though. The apostrophe isn't just extra and unnecessary. The apostrophe is wrong.

  • rob (unregistered)

    In 1986 (before y2k and 4 digit years) I was working on a payroll system where dates were actually stored as part of a fixed length record in a different files. Dates were stored as a 6 digit number, 'yymmdd'. To conserve space (again almost 30 years ago), the date values were actually being stored as packed decimal, so instead of being 6 bytes long, they were only 4 bytes long.

    To put storage costs into perspective, a blank 720K floppy (we had access to a PS/2) cost $8 or so. Most computer systems used as little storage space as possible.

    A senior developer spent a week redoing all of the common FD (file descriptions) used by the cobol program. He redefined all date fields in all of the FD description so that there were separate fields for the year portion, month portion and day portion.

    05 CHECK-RECORD. 10 CHECK-DATE PIC 9(6) COMP-3. 10 FILLER REDEFINES CHECK-DATE. 15 CHECK-DATE-YEAR PIC 9(2). 15 CHECK-DATE-MONTH PIC 9(2). 15 CHECK-DATE-DAY PIC 9(2).

    The senior developer was not happy when I pointed out that this did not work, redefining works on byte boundaries, a packed decimal field uses the first 4 bits for the sign of the number, then the next 4 bits for the most significant digit, then the next byte is used for the next two digits and so on.

  • asdasczxasd (unregistered)

    Java dates are fucked beyond recognition. Today's (6th August 2014) day month and year is is 6, 7, 114.

    Go die in a fire.

  • (cs)

    RIP. Robin Walliams.

  • Peter Wolff (unregistered) in reply to chubertdev
    chubertdev:
    Do real developers double-click the Submit button on a web form?
    Real developers use Lynx.
  • K. (unregistered)

    Backticks code tickbacks

  • K. (unregistered)

    Code section code code code code

  • K. (unregistered)

    Multiline:

    code code

  • K. (unregistered)

    Triple backticks

    trip
trip

Leave a comment on “Tablemania!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article