• (disco) in reply to Arantor
    Arantor:
    fetchObject returns the row as an object, which is basically in this case a standard class instance with each of the columns coming back as public properties in that class. It's basically syntactic sugar.

    Off-topic but this finally explains to me why PDO is better than MySQLi. I'm still using MySQLi for my MUD because the above was not mentioned in any tutorial or comparison I looked at and they otherwise looked similar, and because of that I'm manually writing classes for each non-trivial database table, complete with insert/update/delete/query methods.

    :facepalm:

  • (disco) in reply to Arantor
    Arantor:
    Ah, MySQL's datetime is not epoch related, meaning you can store pre-epoch dates and times if so inclined. It's also good until Y10k.

    I assume you could store pre-epoch dates in MSSQL. Assuming it knows about negative numbers.

  • (disco) in reply to boomzilla

    select CAST(0 AS datetime) 1900-01-01 00:00:00.000

    select CAST(-1 AS datetime) 1899-12-31 00:00:00.000

    select CAST('1899-01-01' AS datetime) 1899-01-01 00:00:00.000

    select CAST(CAST('1899-01-01' AS datetime) AS INT) -365

    Seems to work as expected. MSSQL datetime is also good until Y10k

  • (disco) in reply to Jaloopa
    Jaloopa:
    MSSQL stores datetimes as a numeric representing the number of days since the epoch (01-01-1900 IRC). This allows an unambiguous way of passing them around and converting them

    Number of days, for a datatype that includes time? Hmmm.

    Filed under: 1753, but not 1752

  • (disco) in reply to chubertdev

    Like Excel... integer part indicates days, fractional part indicates hours.

    I think we found TRWTF?

  • (disco) in reply to Arantor

    I work on software that imports excel spreadsheets into sql server. Sometimes time columns are imported in their numeric form. It's exactly as WTFey as you might suspect

  • (disco) in reply to Jaloopa

    Yes, I expect it is.

  • (disco) in reply to Jaloopa
    Jaloopa:
    I work on software that imports excel spreadsheets into sql server. Sometimes time columns are imported in their numeric form. It's exactly as WTFey as you might suspect

    Doesn't the datatype get sniffed by the first 6-8 rows of data?

  • (disco) in reply to Arantor
    Arantor:
    But whatever... what would a datetime column become? Having it as a string is reasonably malleable and means you can strtotime... (oh wait haha)

    Well, there's also date_parse_from_format...

  • (disco) in reply to Jaloopa

    PostgreSQL uses Julian Day, which puts its epoch about six thousand years ago. If your need for dates reaches back that far then whether it supports negative numbers or not is the least of your worries.

    But there's already an unambiguous way of passing dates around as strings.: Obligatory xkcd.

  • (disco) in reply to Watson

    And that's the really clever part. MySQL datetime is yyyy-mm-dd hh:mm:ss.

  • (disco) in reply to Arantor
    Arantor:
    And that's the really clever part. MySQL datetime is yyyy-mm-dd hh:mm:ss.
    What, internally? For display that's also PostgreSQL's default. 
    >    Select current_date
2014-10-25

>    Select CAST(current_date + interval '9000 years' as date)
11014-10-25

    So no Y10k problem there either.

  • (disco) in reply to Watson

    I don't know about internally, since I tend not to care about the internals of how MySQL works. I need to know what to put into it and what I will get out of it, and I know I put in a string of yyyy-mm-dd hh:mm:ss and that's what I get back out again. The internals are not my concern.

  • (disco) in reply to Arantor
    Arantor:
    And that's the really clever part. MySQL datetime is yyyy-mm-dd hh:mm:ss.

    I'm facepalming here over the dozens of people chiming into this thread who don't appear to know that the DATE and DATETIME column types are Standard SQL defined to take and return the above string representation (no cultural representation! only that near-ISO one). There will never be slashes in a SQL date, unless you break compatibility by reconfiguring the format.

    String manipulation may not be optimal, but that's the standard. Go use raw numeric dates if you're incapable of loading a datestring in a specific format into a date object, which all high-level DB access libraries implicitly should. PHP, being PHP, only lets you define it as a string, so you do what you can with what you've got.

  • (disco) in reply to foxyshadis

    In short, TRWTF here is someone not knowing their tools and that PHP has functions for parsing dates (and requiring them in specific formats, no less), or that the Zend_Date class would have methods for manipulating dates - or indeed that the DBMS would have that functionality; a secondary WTF is thinking that the date must have been stored in the database as a string - a matter of not knowing someone else's tools and making unfounded assumptions as a result; tertiary having that string format be ISO-standard yyyy-mm-dd is at all unusual or clever (it is ISO; having a space instead of 'T' to separate date and time is allowed; using 'T' when serialising is suggested because a space is more likely to be a delimiter). Whatever the internal representation (I happen to know PostgreSQL's after inferring it from the allowed range of values).

  • (disco)

    Why are you people worried about 10k?

    That's someone else's problem.

    I mean, I get the 2k, because computers really started taking off in the 80s.

    But 10k could produce technology we can't even imagine.

    Hell, our dating system could change by then.

  • (disco) in reply to xaade
    xaade:
    But 10k could produce technology we can't even imagine.

    Hell, our dating system could change by then.

    well if we keep going the way we're going with pollution we'll be lucky to hit 3k let alone 10k.

    al gore was right, it's an inconvenient truth

  • (disco) in reply to accalia

    Just, don't mention Al Gore.

    100 inches in 10 years Al Gore.

  • (disco) in reply to xaade

    wait....

    10 years.... 100 inches.... 10k years....

    they're all powers of 10. but we're missing one... where's the 1k that completes the pattern?

    </NCIS>

  • (disco) in reply to accalia

    You forgot one.

    Filed under: I'm sorry! Really sorry!

  • (disco) in reply to aliceif

    of course! how could i have been so stupid! we forgot 105!

    Filed under: we also forgot 100

  • (disco) in reply to accalia
    accalia:
    10k
    accalia:
    104

    Um ...

  • (disco) in reply to aliceif

    hmm? (failed hanzo edit)

  • (disco) in reply to xaade
    xaade:
    10k could produce technology we can't even imagine.

    And if not, we'll probably release a patch

  • (disco)

    Al Gore is putting out an R&B album.

    It's called AlGoreRhythms.

  • (disco) in reply to chubertdev

    Bad jokes thread?

  • (disco) in reply to antiquarian

    We don't need one of those.

  • (disco) in reply to chubertdev
    chubertdev:
    Al Gore is putting out an R&B album.

    It's called AlGoreRhythms.

    Al Gore is designing computer software.

    AlGoreRythms.

    Filed under: $('body').css('font-family', 'monospace');

  • (disco) in reply to foxyshadis
    foxyshadis:
    I'm facepalming here over the dozens of people chiming into this thread who don't appear to know that the DATE and DATETIME column types are Standard SQL defined to take and return the above string representation (no cultural representation! only that near-ISO one).

    Hahaha! I use Oracle. :frowning:

Leave a comment on “The Beginning of the Zend”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article