• 50% Opacity (unregistered) in reply to Michael
    Michael:
    JAPH:
    Tizian:
    Why wouldn't he have solved this issue by simply doing this:
    for ($i = 0; $i <= 31; $i++) {
        $date = date('Y-m-d', time()+(86400*i));
        ...<snip>...
    }
    

    86400 doesn't take into account leap seconds or daylight savings time. Also, the value of time() should probably stored outside the loop in the case that the date changes during the iteration.

    time() returns the number of seconds since the epoch in UTC, so daylight saving time is not a problem.

    But that's precisely why it's a problem! Right now + 86400 seconds is not guaranteed to equal tomorrow at the same time. If it's between 0:00 and 0:59 of the night in which the clocks will be set back by 1 hour, then now + 86400 seconds will still equal today.

  • 50% Opacity (unregistered) in reply to 50% Opacity
    50% Opacity:
    Michael:
    JAPH:
    Tizian:
    Why wouldn't he have solved this issue by simply doing this:
    for ($i = 0; $i <= 31; $i++) {
        $date = date('Y-m-d', time()+(86400*i));
        ...<snip>...
    }
    

    86400 doesn't take into account leap seconds or daylight savings time. Also, the value of time() should probably stored outside the loop in the case that the date changes during the iteration.

    time() returns the number of seconds since the epoch in UTC, so daylight saving time is not a problem.

    But that's precisely why it's a problem! Right now + 86400 seconds is not guaranteed to equal tomorrow at the same time. If it's between 0:00 and 0:59 of the night in which the clocks will be set back by 1 hour, then now + 86400 seconds will still equal today.

    ...in your local timezone I wanted to add. Unless you keep everything in UTC.

  • Jazz (unregistered)

    ITT: People who never even tried to learn how to use PHP well insisting that it's not possible to use PHP well, much like someone who has never played the piano may conclude that nobody, anywhere, has ever played the piano.

  • (cs) in reply to snoofle
    snoofle:
    re: Daylight Saving Time...

    Here at WTF Inc, our code is heavily dependent upon date calculations. Dealing with transactions that occur in the middle of a DST switch would greatly complicate the home grown libraries we have. As such, the authors instituted, and management approved a procedural rule that suspends all processing for two hours on either side of a DST change.

    Wait... management approved something eminently sensible and efficient? You lucky dog to be working there.

    Now all ya gotta do is implement the same lockout for those leap-days and leap-seconds that have brought every known date-time software system to a grinding halt.

  • Tasty (unregistered) in reply to robbak
    robbak:
    daveyk:
    Eric TF Bat:
    but Queensland doesn't suffer from that because the farmers don't want to confuse their cows...
    It is actually because if we introduce daylight savings then the curtains will fade.
    It's actually because the populous south east of the state is geographically in the wrong timezone, meaning it is permanently in daylight savings mode, and the north of the state is tropical so there is little difference between summer and winter, apart from the weight of the constant rain.

    Queensland suffers from too many farmers and cows. The state needs more koalas and lungfish!

  • Michael (unregistered) in reply to 50% Opacity
    50% Opacity:
    50% Opacity:
    Michael:
    JAPH:
    Tizian:
    Why wouldn't he have solved this issue by simply doing this:
    for ($i = 0; $i <= 31; $i++) {
        $date = date('Y-m-d', time()+(86400*i));
        ...<snip>...
    }
    

    86400 doesn't take into account leap seconds or daylight savings time. Also, the value of time() should probably stored outside the loop in the case that the date changes during the iteration.

    time() returns the number of seconds since the epoch in UTC, so daylight saving time is not a problem.

    But that's precisely why it's a problem! Right now + 86400 seconds is not guaranteed to equal tomorrow at the same time. If it's between 0:00 and 0:59 of the night in which the clocks will be set back by 1 hour, then now + 86400 seconds will still equal today.

    ...in your local timezone I wanted to add. Unless you keep everything in UTC.

    You are right. That's why I do everything in UTC until display. This is why you should NEVER do date calculations manually!

  • Dominic (unregistered) in reply to Tizian
    Tizian:
    Why wouldn't he have solved this issue by simply doing this:
    for ($i = 0; $i <= 31; $i++) {
        $date = date('Y-m-d', time()+(86400*i));
        ...<snip>...
    }
    

    Because convenient assumptions about time are always wrong.

  • (cs) in reply to Franky

    This:

    Franky:
    am I the only one who looks at

    date('Y-m-d', strtotime("+$i days"))

    and gets blood in the eyes regarding "+$i days" parsing to today in x days? I mean, seriously, is there no DateTime.Today.AddDays(i) in php?

    PHP is definitely TRWTF.

  • Bananas (unregistered) in reply to erat
    erat:
    I think developers of this caliber don't really have "Swiss army knives" so much as "Swiss army hammers."
    And when all you have is a hammer, everything looks like a nail.
  • (cs) in reply to 50% Opacity
    50% Opacity:
    But that's precisely why it's a problem! Right now + 86400 seconds is not guaranteed to equal tomorrow at the same time. If it's between 0:00 and 0:59 of the night in which the clocks will be set back by 1 hour, then now + 86400 seconds will still equal today.

    DST adjustments occur at 02:00 local time and can therefore never cause the date to go backwards.

  • 50% Opacity (unregistered) in reply to DES
    DES:
    50% Opacity:
    But that's precisely why it's a problem! Right now + 86400 seconds is not guaranteed to equal tomorrow at the same time. If it's between 0:00 and 0:59 of the night in which the clocks will be set back by 1 hour, then now + 86400 seconds will still equal today.

    DST adjustments occur at 02:00 local time and can therefore never cause the date to go backwards.

    I didn't say the date would go backwards. I said 0:00 + 86400 seconds - 1h DST = still today.

    Man, time math really does seem to be hard. Even the correctors correct incorrectly.

  • (cs) in reply to 50% Opacity
    50% Opacity:
    DES:
    50% Opacity:
    But that's precisely why it's a problem! Right now + 86400 seconds is not guaranteed to equal tomorrow at the same time. If it's between 0:00 and 0:59 of the night in which the clocks will be set back by 1 hour, then now + 86400 seconds will still equal today.

    DST adjustments occur at 02:00 local time and can therefore never cause the date to go backwards.

    I didn't say the date would go backwards. I said 0:00 + 86400 seconds - 1h DST = still today.

    Man, time math really does seem to be hard. Even the correctors correct incorrectly.

    "incorrectors"

  • (cs)

    All programmers should know that knowledge of the past is very valuable. In the past previous programmers have done LOTS of work, and if you are any good, repeating said work will inevitably be wrong.

    Moral of the story: Find the proper library and USE it!

  • jay (unregistered) in reply to ZoomST
    ZoomST:
    Didn't know that
    ...<snip>...
    can be used in SQL and in PHP as well. Would it work in Java? I think I'll try...

    In Java you have to write

    java.lang.snip(System.ellipses.LEFT(),System.ellipses.RIGHT());
    
  • jay (unregistered) in reply to MiniMax
    MiniMax:
    It's about more than dates and languages. It's about being humble. It's about thinking "Ohh, I have this problem, and I am sure I'm not the center of the universe, so it's a good bet that someone else have had a similar problem in the past. So why don't I go see if I can't find an existing solution to my problem instead of trying to be clever and do it all on my own."

    I can comprehend someone thinking, "Maybe I'm the first person ever to want to create an ASP.NET GridView object with a column appended at run-time where the type of control for the column depends on the value in a table so each row can be a different control type" ... or something fairly weird like that. Or even if you're not the first person ever to want to do that, the requirement is detailed and odd enough that it's realistic to suppose that no one else has ever wanted to do EXACTLY that.

    But, "Maybe I'm the first person in history ever to want to know what tomorrow's date will be"? Doesn't that just seem ... unlikely?

  • Jazz (unregistered) in reply to chubertdev
    chubertdev:
    This:
    Franky:
    am I the only one who looks at

    date('Y-m-d', strtotime("+$i days"))

    and gets blood in the eyes regarding "+$i days" parsing to today in x days? I mean, seriously, is there no DateTime.Today.AddDays(i) in php?

    PHP is definitely TRWTF.

    http://www.php.net/manual/en/datetime.add.php, you mindless numbskull. Just because you can't figure out how to write good PHP doesn't mean nobody else can.

  • jay (unregistered)

    This is yet another example of why we should:

    (a) Eliminate daylight savings time (b) Eliminate leap years (c) Strangle the person who thought leap seconds were a good idea and throw his body to the zombies (d) Make all months the same length. I suggest 13 months of 28 days each. (e) Abolish hours, minutes, and seconds and instead divide the day into 100 centidays.

    Think how much simpler all of our lives would be.

  • 50% Opacity (unregistered) in reply to jay
    jay:
    This is yet another example of why we should:

    (a) Eliminate daylight savings time (b) Eliminate leap years (c) Strangle the person who thought leap seconds were a good idea and throw his body to the zombies (d) Make all months the same length. I suggest 13 months of 28 days each. (e) Abolish hours, minutes, and seconds and instead divide the day into 100 centidays.

    Think how quickly we'd get out of sync with stupid reality in which we're circling around a permanent nuclear fusion bomb which does not care about our tiny obsessive minds needing to number everything and how meaningless our new super calendar would become.

    FTFY.

  • someguy (unregistered) in reply to jay
    This is yet another example of why we should:

    (a) Eliminate daylight savings time (b) Eliminate leap years (c) Strangle the person who thought leap seconds were a good idea and throw his body to the zombies (d) Make all months the same length. I suggest 13 months of 28 days each. (e) Abolish hours, minutes, and seconds and instead divide the day into 100 centidays.

    Think how much simpler all of our lives would be.

    Just use .beats already or something.

  • (cs) in reply to someguy
    someguy:
    This is yet another example of why we should:

    (a) Eliminate daylight savings time (b) Eliminate leap years (c) Strangle the person who thought leap seconds were a good idea and throw his body to the zombies (d) Make all months the same length. I suggest 13 months of 28 days each. (e) Abolish hours, minutes, and seconds and instead divide the day into 100 centidays.

    Think how much simpler all of our lives would be.

    Just use .beats already or something.

    The swatch beat is rubbish. It ought to be the length of a heartbeat if anything.

  • Jimbo (unregistered) in reply to Eric TF Bat
    Eric TF Bat:
    I worked on a project once that used date functions and failed, but only in some (Australian) states. It was written and thoroughly tested in Queensland, but failed in New South Wales and Victoria. Turns out there are times when the number of seconds from midnight to midnight is not exactly 24x60x60, due to daylight savings -- but Queensland doesn't suffer from that because the farmers don't want to confuse their cows...
    Me too. We were once centralised stuff so everything was done in Sydney, and local time was calculated in different ways in different places (the people who originally wrote the software had obviously considered that this might one day happen). Everything seemed to be ok, asx we brought the Eastern states onto the main server until Daylight savings hit. Suddenly, something that was supposed to take 30 seconds was taking 2 hours and 30 seconds in QLD. Took us ages to find that the start time was calculated by
    CURRTIME (AEDT) - 11 (Daylight offset) + 10 (Standard offset - QLD has no Daylight savings) 
    
    but the end time was (accidentally) calculated as
    CURRTIME - 10 (Standard) + 11 (Daylight) 

    Fun times. Qld farmers and their cows have a lot to answer for - although I suppose we would have had similar issues irrespective of Daylight Savings if the Central and Western timezones had already been cut across....

  • F***-it Fred (unregistered)

    Whenever I see such awful date handling code, part of me wonders if it's sheer incompetence or if it's designed to fail after a certain date, as a way of screwing things over after the person behind it leaves, while being ugly enough that the time bomb is not immediately obvious.

  • EmperorOfCanada (unregistered)

    Sometimes you just forget and don't have access to the net. I don't know how many times that I have forgotten some basic function (i.e. String splitting in c++) and I am on the road without net access so you cobble together something with the full intention of replacing it with the proper function in the morning (5 years later it is still there looking horrible)

    For me it is often less a symptom of being stupid as a symptom of switching languages too frequently. Personally I work with PHP, C++, Objective-C, Python, and Octave. I often have to look up the basics.

  • goochrules (unregistered) in reply to Franky
    Franky:
    am I the only one who looks at

    date('Y-m-d', strtotime("+$i days"))

    and gets blood in the eyes regarding "+$i days" parsing to today in x days? I mean, seriously, is there no DateTime.Today.AddDays(i) in php?

    PHP 5.3 introduced some useful datetime constructs, DatePeriod seems appropriate in this case:

    $start = new DateTime(); $end = new DateTime(); $end->modify('+1 month'); $interval = new DateInterval('P1D'); $dp = new DatePeriod($start, $interval, $end); foreach($dp as $date) { // do something }

  • mialer (unregistered) in reply to Jimbo
    Jimbo:
    Eric TF Bat:
    I worked on a project once that used date functions and failed, but only in some (Australian) states. It was written and thoroughly tested in Queensland, but failed in New South Wales and Victoria. Turns out there are times when the number of seconds from midnight to midnight is not exactly 24x60x60, due to daylight savings -- but Queensland doesn't suffer from that because the farmers don't want to confuse their cows...
    Me too. We were once centralised stuff so everything was done in Sydney, and local time was calculated in different ways in different places (the people who originally wrote the software had obviously considered that this might one day happen). Everything seemed to be ok, asx we brought the Eastern states onto the main server until Daylight savings hit. Suddenly, something that was supposed to take 30 seconds was taking 2 hours and 30 seconds in QLD. Took us ages to find that the start time was calculated by
    CURRTIME (AEDT) - 11 (Daylight offset) + 10 (Standard offset - QLD has no Daylight savings) 
    
    but the end time was (accidentally) calculated as
    CURRTIME - 10 (Standard) + 11 (Daylight) 

    Fun times. Qld farmers and their cows have a lot to answer for - although I suppose we would have had similar issues irrespective of Daylight Savings if the Central and Western timezones had already been cut across....

    TRWTF is a train that has it's own timrezone.... http://en.wikipedia.org/wiki/Time_in_Australia#anomalies Akismet wears poo-catchers

  • Bill C. (unregistered) in reply to anonymous
    anonymous:
    I'm starting to wonder if I hate working with dates simply because they ARE a pain, or because more often than not we find code that makes it twice the pain...
    There are better things to do with dates than work with them, but sometimes they're still a pain.
  • löchlein deluxe (unregistered) in reply to Tizian
    Tizian:
    Why wouldn't he have solved this issue by simply doing this:
    for ($i = 0; $i <= 31; $i++) {
        $date = date('Y-m-d', time()+(86400*i));
        ...<snip>...
    }
    

    Simple, daylight savings time.

  • Curtis P (unregistered) in reply to phord
    phord:
    I love the gnu date parsers.

    $ date --date "2 fortnights from last Tuesday"

    http://www.gnu.org/software/coreutils/manual/html_node/Relative-items-in-date-strings.html#Relative-items-in-date-strings

    The date function bundled with Ubuntu doesn't like this.

  • bitti (unregistered)

    TRWTF is that someone considers himself a much better programmer and still reproduces the same RC problem as in the original code. The fix would be easy:

    $now = time();
    for ($i = 0; $i <= 31; $i++) {
        $date = date('Y-m-d', strtotime("+$i days", $now));
        ...<snip>...
    }

    The RC is unlikely anyway? Exactly these kinds of RCs are the ones which will hit you in production when you least expect it. And because they are so seldom they hard to reproduce or to find through prior testing.

  • ChrisM (unregistered) in reply to olaf

    It's a heredoc:

    http://www.php.net/manual/en/language.types.string.php#language.types.string.syntax.heredoc

  • (cs) in reply to zennnnnn
    zennnnnn:
    Many setups will have one mysql server and multiple webservers. For time consistency it makes sense in those situations to use the database for time.
    No, not really. It makes sense to use NTP to synchronise the clocks on all the machines, and to WORK IN [redacted] UTC UNTIL YOU NEED TO BARF RESULTS TO THE USER!
  • Bob (unregistered) in reply to ip-guru
    ip-guru:
    olaf:
    "<<<SQL" wth, whats that? Anyone got a php.net link for that? Thanks</div>

    it is called herdoc format & is actually quite usefully if you have multi-line strings especially if they contain a mix of double & single quotes

    that does not make it an less of a WTF though

    Actually "heredoc syntax" - at least in PHP world. Also know as EOF notation.

  • Andrew (unregistered) in reply to jay

    TRWTF is DST and time zones.

    In this age of global communication everyone should just use UTC.

    Same with leap seconds, most people couldn't care less that whatever the current time is according to UTC is 35 seconds off from TAI.

  • jay (unregistered) in reply to 50% Opacity
    50% Opacity:
    jay:
    This is yet another example of why we should:

    (a) Eliminate daylight savings time (b) Eliminate leap years (c) Strangle the person who thought leap seconds were a good idea and throw his body to the zombies (d) Make all months the same length. I suggest 13 months of 28 days each. (e) Abolish hours, minutes, and seconds and instead divide the day into 100 centidays.

    Think how quickly we'd get out of sync with stupid reality in which we're circling around a permanent nuclear fusion bomb which does not care about our tiny obsessive minds needing to number everything and how meaningless our new super calendar would become.

    FTFY.

    In what holy book is it written that our calendar year must exactly match the length of time that it takes the Earth to make one revolution about the Sun?

    If we abolished leap years, then yes, the date on which seasons start would change from year to year. So what? I think a simple, systematic calendar would have more benefits than a calendar in which the equinox always occurs on the same date. Which do you do more often: Think about how many days until your next payday, or think about how many days until the next vernal equinox?

  • jay (unregistered) in reply to someguy
    someguy:
    This is yet another example of why we should:

    (a) Eliminate daylight savings time (b) Eliminate leap years (c) Strangle the person who thought leap seconds were a good idea and throw his body to the zombies (d) Make all months the same length. I suggest 13 months of 28 days each. (e) Abolish hours, minutes, and seconds and instead divide the day into 100 centidays.

    Think how much simpler all of our lives would be.

    Just use .beats already or something.

    Hmm, not clear why we need to create a new time zone for "internet time". Don't we already have UTC?

    As to 1000 beats per day, okay, I'd rather call them millidays then beats, might as well stay consistent with the established metric system.

    But yeah, I agree with the concept.

  • (cs) in reply to Jazz
    Jazz:
    chubertdev:
    This:
    Franky:
    am I the only one who looks at

    date('Y-m-d', strtotime("+$i days"))

    and gets blood in the eyes regarding "+$i days" parsing to today in x days? I mean, seriously, is there no DateTime.Today.AddDays(i) in php?

    PHP is definitely TRWTF.

    http://www.php.net/manual/en/datetime.add.php, you mindless numbskull. Just because you can't figure out how to write good PHP doesn't mean nobody else can.

    That's still super WTF-ery. It feels like order off of a menu.

    "Hey, I have this date here, and can you super-size it? By how much? Oh yeah, 10 days."

  • (cs) in reply to goochrules
    goochrules:
    Franky:
    am I the only one who looks at

    date('Y-m-d', strtotime("+$i days"))

    and gets blood in the eyes regarding "+$i days" parsing to today in x days? I mean, seriously, is there no DateTime.Today.AddDays(i) in php?

    PHP 5.3 introduced some useful datetime constructs, DatePeriod seems appropriate in this case:

    $start = new DateTime(); $end = new DateTime(); $end->modify('+1 month'); $interval = new DateInterval('P1D'); $dp = new DatePeriod($start, $interval, $end); foreach($dp as $date) { // do something }

    But only about half of PHP sites are 5.3+

  • 50% Opacity (unregistered) in reply to jay
    jay:
    50% Opacity:
    jay:
    This is yet another example of why we should:

    (a) Eliminate daylight savings time (b) Eliminate leap years (c) Strangle the person who thought leap seconds were a good idea and throw his body to the zombies (d) Make all months the same length. I suggest 13 months of 28 days each. (e) Abolish hours, minutes, and seconds and instead divide the day into 100 centidays.

    Think how quickly we'd get out of sync with stupid reality in which we're circling around a permanent nuclear fusion bomb which does not care about our tiny obsessive minds needing to number everything and how meaningless our new super calendar would become.

    FTFY.

    In what holy book is it written that our calendar year must exactly match the length of time that it takes the Earth to make one revolution about the Sun?

    If we abolished leap years, then yes, the date on which seasons start would change from year to year. So what? I think a simple, systematic calendar would have more benefits than a calendar in which the equinox always occurs on the same date. Which do you do more often: Think about how many days until your next payday, or think about how many days until the next vernal equinox?

    If we do not sync our calendar with some real world rhythm, it basically becomes entirely arbitrary and we don't need any "months" or anything of that sort and can indeed go straight to Swatch .beats or UNIX epoch timestamps. If months don't correspond to seasons at all, there's no real use for them. Right now months are useful to get a feeling for what the outside conditions will be at a given time. "Oh yeah, you don't want to do that in October, it's gonna be too cold outside for that." Without this correlation, months become entirely arbitrary and useless; just use powers of ten when you need "big time units".

    If you don't have leap seconds, the clock will drift and diverge from the day/night cycle. So at 10am it could be entirely dark outside. So clock time becomes meaningless as well. Then we'll just go for a continuous counter like UNIX epoch time. "We'll have a meeting at 3728884822, okay?" You can get your pay checks every full fifty thousand seconds or so.

    Does that sound like a more useful system? Time is complicated as it is because humans need it in humanly understandable units to be useful to them, and those units need to be synced to a natural rhythm, again to be useful. And unfortunately reality doesn't happen to be divisible by ten.

  • (cs)

    Yesterday I wanted to change a windows batch script to give a run duration. The search results seemed to indicate it doesn't have date functions either so I just echoed the start and end time and since all I need is a ballpark figure I calculated the duration in my head :P

  • Norman Diamond (unregistered) in reply to 50% Opacity
    50% Opacity:
    jay:
    In what holy book is it written that our calendar year must exactly match the length of time that it takes the Earth to make one revolution about the Sun?
    If we do not sync our calendar with some real world rhythm, it basically becomes entirely arbitrary and we don't need any "months" or anything of that sort and can indeed go straight to Swatch .beats or UNIX epoch timestamps. If months don't correspond to seasons at all, there's no real use for them. Right now months are useful to get a feeling for what the outside conditions will be at a given time.
    Some ancient civilizations are more respected than others because they developed sophisticated calendars. Figuring out the right time to plant crops always depends on guesswork, but good calendars made good guesses a lot more likely. For harvesting they could look at the crops and decide if the crops look ready for harvesting, but for planting they don't get such clues.

    In spring, is today's warm weather a signal or is it more likely a fluke? Calendars that made a year approximately equal to one revolution around the sun, with a month equal to one revolution of the moon around the earth, with leap months added to keep years roughly in sync with revolutions around the sun, did wonders in helping farmers guess the most likely answer.

  • vo (unregistered) in reply to jay
    jay:
    ZoomST:
    Didn't know that
    ...<snip>...
    can be used in SQL and in PHP as well. Would it work in Java? I think I'll try...

    In Java you have to write

    java.lang.snip(System.ellipses.LEFT(),System.ellipses.RIGHT());
    

    In Python you have to write

    ...<snip>...
    
  • Adam (unregistered) in reply to Jeremy
    Secondly, it falls into the same trap that half these TDWTFs do. Namely that the developer isn't aware of their own limitations, or are unable to identify when something is needlessly complicated. It should be pretty obvious to anyone doing this that it's not "the answer".

    Can I frame this and hang it on the wall?

  • Norman Diamond (unregistered) in reply to Adam
    Adam:
    Secondly, it falls into the same trap that half these TDWTFs do. Namely that the developer isn't aware of their own limitations, or are unable to identify when something is needlessly complicated. It should be pretty obvious to anyone doing this that it's not "the answer".
    Can I frame this and hang it on the wall?
    If you don't know, we don't know either.

    Now I'm confused. Does this mean you are aware of your own limitations or you aren't aware of your own limitations?

  • Jeremy (unregistered) in reply to Norman Diamond
    Norman Diamond:
    Adam:
    Secondly, it falls into the same trap that half these TDWTFs do. Namely that the developer isn't aware of their own limitations, or are unable to identify when something is needlessly complicated. It should be pretty obvious to anyone doing this that it's not "the answer".
    Can I frame this and hang it on the wall?
    If you don't know, we don't know either.

    Now I'm confused. Does this mean you are aware of your own limitations or you aren't aware of your own limitations?

    You can know you don't know everything. Too many programmers think they have to solve every task with the things they already have in their head.

    There are tasks like "My client wants to give 10% off, if they have 3 items, one of which is a coffee mug, on odd numbered Tuesdays" and there are tasks like "I need to add 1 day to today" or "I need to reformat yyyy-mm-dd into mm/dd/yyyy".

    It bugs me that people so often fail to see the difference in those problems. One you're just going to have to attack all alone. The others are things that it must be true that tons of people are doing ALL THE TIME. If it SEEMS like there should be an easier way, there probably is. Surely no one can think that in order to get the next month of dates you have to make a SQL table, ask mysql to insert 32 dates (not in a loop), and then have some jumbled mess of a query ask for what you just explicitly inserted back.

    As with any good TDWTF they even do it the stupid way the stupid way, but, again, I'll never understand how people don't get 70% of the way through a "solution" like this without realizing there MUST be a better way.

  • TycleStype (unregistered)
    Comment held for moderation.
  • TycleStype (unregistered)
    Comment held for moderation.

Leave a comment on “PHP Doesn't Have Date Functions Either”

Log In or post as a guest

Replying to comment #412864:

« Return to Article