• someone (unregistered)

    They have a Tabitha and a Tabatha in the office? How confusing.

    But the name reminds me of "Bridge to Terabithia", great movie...

  • noland (unregistered)

    This is obviously the date-algorithm for a planet rotating around a twin star. Early in the year the gravitation of the two stars add up resulting in some interesting turbulences in the day-times and their sequence. A harbinger of some really aggressive marketing strategies ...

  • emaNrouY-Here (unregistered) in reply to emaNrouY-Here

    Oh, and for your enjoyment... Month Day Year Begin Date End Date 1 1 2000 0/22/1999 1-1-2000 1 2 2000 0/23/1999 1-2-2000 1 3 2000 0/24/1999 1-3-2000 1 4 2000 0/25/1999 1-4-2000 1 5 2000 0/26/1999 1-5-2000 1 6 2000 0/27/1999 1-6-2000 1 7 2000 0/28/2000 1-7-2000 1 8 2000 1-23-2000 1-8-2000 1 9 2000 1-23-2000 1-9-2000 12 21 1999 12-23-1999 12-21-1999 12 22 1999 12-23-1999 12-22-1999 12 23 1999 12-23-1999 12-23-1999 12 24 1999 12-23-1999 12-24-1999 12 25 1999 12-23-1999 12-25-1999 12 26 1999 12-23-1999 12-26-1999 12 27 1999 12-23-1999 12-27-1999 12 28 1999 12-23-1999 12-28-1999 12 29 1999 12-23-1999 12-29-1999 12 30 1999 12-23-1999 12-30-1999 12 31 1999 12-23-1999 12-31-1999

  • fjf (unregistered) in reply to Ivan Godard
    Ivan Godard:
    The reason 13x28 day months are used in accounting (not just finance) is to make year-to-year results comparable. Without months being even modulo weeks there would be some years with a few percent more business days in them than others, leading to random variations in year-to-year (and month to month) results, which noise would swamp the signal of how the business is doing. It's GAAP. Before laughing at a non-techy, learn a bit about why it's done that way, and then see if you can figure out a better way. Harvard Business School would love to hear from you.
    How about comparing results per time unit rather than absolute results (like they do in physics with power and various other quantities)? That would also take care of holidays. Do they teach division at business schools?
  • (cs) in reply to Valued Service
    Valued Service:
    Dom:
    Surely the "human system for reckoning time" is based on the Earth's rotation and its orbit around the Sun. Maybe the blame lies with God.

    The problem is that the rotation around the sun doesn't occur at an exact number of earth's rotations. Which means that every year occurs within 365.xx days. That little xx is what causes our years to have extra days in them.

    We try to fit in those extra days by blowing up that fraction until we have how many days per set of years. But the fraction is so precise that we can't use filler days with any degree of sanity. Plus, we don't have a precise calculation for that fraction, so we find out every now and then we're off by an hour or so.

    Because we like base 10 so much, instead of adding days per x years. We add 1 day per 4 years except every 100 years except every 1000 years. So 1700, 1800, 1900 not a leap year, but 2000 is.

    This is all because we prefer our years to land on solar dates.

    We could of course switch back to a lunar calendar.

    Solar dating isn't just "a preference"; there's a real, practical reason behind it. The solar cycle is tied to the cycle of seasons, which has a major effect on how we live our lives. For example, you wouldn't participate in a lot of the same activities in the winter that you do in the summer, or vice versa. (Especially if you live at a latitude where there's a significant difference between the two.)

    The lunar cycle has a lot less of an effect on our lives than that, which is why it's not our principal method of keeping time.

  • (cs)

    Dates & Time... Dates as sane people should know are reckoned in seconds from the epoch (1-1-1970). The display of dates (and time) is a user problem.

    As for programmers being awake at 7:15AM, that usually only happens when they have been pulling an "all nighter", as everyone knows.

    Real programmers don't do work on times with single digits (using a 24 hour clock). They need rest somehow.

  • BillR (unregistered) in reply to Don'tneedastinkingname
    Don'tneedastinkingname:
    The real wtf is the arse backwards American date format. Amirite?

    No, the real WTF is not storing everything in epoch seconds GMT and then converting based on the TZ info of the person/client viewing the data, the local time of the server, local time GMT, whatever fits best. That conversion could then include things like presenting arse-forward dates to accessors in the UK and the like.

    If you need the date of the start of last week, it's really, really easy to do that when you have a single INT to work worth, rather than dates that look right in the States, or in the UK, or whatever. As it stands, nobody knows what TZ those dates came from, and so the script is impossible to use outside that one TZ, which renders the data mostly useless as well. If you run that script in Japan, you've got a completely different set of bugs that popping up than if you ran it in Dublin. That may seem like an extreme example, but pretend Corporate moves from New York to California. Same problem, just different scale.

  • Ron (unregistered) in reply to emaNrouY-Here

    [code] If curDay > 7 Then beginday = day(curDate) - 7 [code]

    You left a reference to the actual current date in your macro, and that is why you have so many 23's in your output

  • Tam (unregistered)

    Sure, we could just keep an integer count of days since wheneveritwas. That would be an improvement.

    But terribly Earth-centered, don't you think? And which city gets to be the first to greet the new day? Greenwich? Why them? That far-east Xanadu island? Nobody lives there since global warming flooded it.

    Really, you need to future proof your code. By the time the stuff you write today is fully replaced, we'll be a spacefaring civilization. We need Universal Time, and we need it now*.

    • Disclaimer: the term "now" is only valid in certain reference frames.
  • smf (unregistered) in reply to RonBeck62
    RonBeck62:
    I'm with Tabitha. The code is bug-free. 
      Sub PopulateDates()
    txtBeginDate.Text = Now.AddDays(-7).ToShortDateString
    txtEndDate.Text = Now.ToShortDateString
  End Sub

    There is a bug if the date rolls over between txtBeginDate is set and when txtEndDate is set.

  • (cs) in reply to smf
    troll:
    There is a bug if the date rolls over between txtBeginDate is set and when txtEndDate is set.

    Why, yes there is, unregistered person.

  • jay (unregistered) in reply to QJo
    QJo:
    Of course, the *real* WTF is that both Jeff and Tabitha are working at 7:15. Which 7:15 it is, they don't say (another failure of the US way; the civilised world uses the 24-hour clock). Either this is 7:15 pm, which means that they're both staying late, or they start *really early* in the morning.

    If I'm working at 7:15am, it's because I haven't quit from the day before yet.

  • Evan (unregistered) in reply to QJo
    QJo:
    Of course, the *real* WTF is that both Jeff and Tabitha are working at 7:15. Which 7:15 it is, they don't say (another failure of the US way; the civilised world uses the 24-hour clock). Either this is 7:15 pm, which means that they're both staying late, or they start *really early* in the morning.
    I find apparent deliberate misunderstanding to be really annoying, but I do agree that I wish that the US would switch to 24-hour time. That was one thing I took away from my visit to Europe. (In particular, I find it useful for alarms. I virtually never actually sleep through an alarm, but I used to with moderate regularity mis-set the alarms -- usually for the wrong AM/PM-ness. That problem just evaporates if you use 24-hour time.)

    Though I do think you're overstating the case; I've been in 3 different European countries (or really 5 or even 6 if you stretch how you count) including Norway, the UK, and Hungary, and my memory was that it wasn't all that rare to see AM/PM times in any of them. So it's not like Europe is exclusively on 24-hour time the way the US is essentially on exclusively 12-hour time.

  • jay (unregistered) in reply to @Deprecated
    @Deprecated:
    Somebody help me out here... WTF was the programmer doing?

    Here are a selection of dates run through this bizarre algorithm: Good WTF 12/05/1999: 10/25/1999 01/18/2000: 0/11/2000 01/23/2000: 0/16/2000 02/12/2000: 1/5/2000 03/20/2000: 2/13/2000 12/15/2000: 11/8/2000 01/19/2001: 0/12/2001 02/06/2001: 0/26/2000 02/15/2001: 1/8/2001 02/28/2001: 1/21/2001 04/17/2001: 3/10/2001 06/10/2001: 5/3/2001 09/06/2001: 7/26/2001 10/24/2001: 9/17/2001 12/22/2001: 11/15/2001 01/21/2002: 0/14/2002 02/20/2002: 1/13/2002 03/25/2002: 2/18/2002 10/24/2002: 9/17/2002 12/19/2002: 11/12/2002 01/12/2003: 0/5/2003 02/18/2003: 1/11/2003 03/05/2003: 1/25/2003 03/28/2003: 2/21/2003 04/11/2003: 3/4/2003 05/03/2003: 3/23/2003 09/29/2003: 8/22/2003 10/11/2003: 9/4/2003 11/23/2003: 10/16/2003 11/23/2003: 10/16/2003 12/18/2003: 11/11/2003 02/01/2004: 0/21/2003 03/24/2004: 2/17/2004 03/24/2004: 2/17/2004 04/23/2004: 3/16/2004 08/27/2005: 7/20/2005 10/02/2005: 8/22/2005 11/30/2005: 10/23/2005 12/04/2005: 10/24/2005 12/09/2005: 11/2/2005 12/22/2005: 11/15/2005 01/26/2006: 0/19/2006 02/25/2006: 1/18/2006 04/22/2006: 3/15/2006 04/12/2007: 3/5/2007 04/12/2007: 3/5/2007 06/03/2007: 4/23/2007 10/13/2007: 9/6/2007 11/19/2007: 10/12/2007 12/27/2007: 11/20/2007 01/04/2008: -1/24/2008 02/12/2008: 1/5/2008 02/19/2008: 1/12/2008

    My favourite has to be -1/24/2008.

    It is pretty obvious what TRWTF is this time... m/d/y :-p

    Edit: Let me qualify I used Java Calendar to get the year, month, and day of month, which I assumed was the same as VB's, and may be an invalid assumption.

    Umm ... no. The algorithm is weird, but not that weird.

    12/05/1999: 11/26/1999 01/18/2000: 01/11/2000 01/23/2000: 01/16/2000 02/12/2000: 2/5/2000

    ... etc ...

    You seem to be thinking that when he does the "day - 7", that this will somehow update the value in month and year. No.

    In general, if the day of the month > 7, the algorithm will get the date 7 days earlier. That should work fine. Round-about way to get there, but it looks to me like it will give the correct answer.

    If the day < = 7 and the month>1, it will get a day that is almost sort of one week before. He doesn't handle that complex idea of months having different numbers of days, but at least he'll give valid dates.

    Where he falls down is when month = 1 and day <=7. He subtracts 1 from the month, giving 0. He then rolls the year back, but he doesn't set the month to 12. So

    01/01/2000 -> 00/22/1999

    Presumably after "beginyear=year-1" he should say "beginmonth=12".

    Also, his first test is "> 7 ... else", but is second test is "<7", thus giving wrong behavior when day = 7. Namely

    01/07/2000 -> 00/28/2000

    That test should be "<=7", combined with

  • jay (unregistered)

    Umm, how would replacing this function with ToShortDateString work? The point of this function -- flawed as it is -- appears to be to calculate a date one day prior to the current date, and then populate a "begin date" field with that date and an "end date" field with the current date. ToShortDateString does none of these things. Replacing a buggy function with a function that works correctly but does something totally different from what is required does not seem like a very good solution. Why not just replace the function with a call to Math.max?

  • jay (unregistered)

    On the serious side, the programmer's problem is that he is trying to do date arithmetic by doing all the "carries" between date fields himself. This is a waste of time and very often results in exactly the sort of errors he has here: failing to properly deal with running across year boundaries, getting the right length for each month (which he doesn't even try to do here), forgetting about daylight savings time and leap years, etc.

    I think the smart way to do most date arithmetic is to work with the date in a "number of days since the beginning of the world" or similar format. Convert from a display format to the "julian" format, do all your arithmetic, then convert back. Then all the rollover issues and daylight savings time and all that basically just go away, or in a sense are handled by the standard library date conversion routines. Even if you had to write this library yourself, it would be better to do it once and re-use, than to have to re-do it all every time you need a date calculation.

    Admittedly, this falls down when you have date arithmetic like "add 1 month to today's date". Still, it makes more sense to create a set of standard functions to do date arithmetic and call them -- or use existing library functions if the language provides them -- then to re-write the same logic every time you need date arithmetic.

  • urza9814 (unregistered) in reply to Pock Suppet
    Pock Suppet:
    Don'tneedastinkingname:
    And if there are computer programmers who do not have the basic intelligence to be able to understand how a calendar works, they have absolutely no business being in the industry.

    And yet... There they are.

    The real wtf is the arse backwards American date format. Amirite?

    Urong. The only format any programmer should ever use is yyyy-mm-dd. Period.

    What about SSSSSSSSSS?

  • Your Name (unregistered) in reply to Tam
    Tam:
    Sure, we could just keep an integer count of days since wheneveritwas. That would be an improvement.

    But terribly Earth-centered, don't you think? And which city gets to be the first to greet the new day? Greenwich? Why them? That far-east Xanadu island? Nobody lives there since global warming flooded it.

    Really, you need to future proof your code. By the time the stuff you write today is fully replaced, we'll be a spacefaring civilization. We need Universal Time, and we need it now*.

    • Disclaimer: the term "now" is only valid in certain reference frames.

    I propose a new universal standard where you calculate time based on number of Planck Times since the Big Bang. I think a 512-bit integer type should be able to hold all of them until the heat death of the universe.

    I'll leave implementation up to you; I expect a working prototype within the next 10^46 planck times.

  • F (unregistered) in reply to urza9814
    urza9814:
    Pock Suppet:
    Don'tneedastinkingname:
    And if there are computer programmers who do not have the basic intelligence to be able to understand how a calendar works, they have absolutely no business being in the industry.

    And yet... There they are.

    The real wtf is the arse backwards American date format. Amirite?

    Urong. The only format any programmer should ever use is yyyy-mm-dd. Period.

    What about SSSSSSSSSS?

    That's a time format, not a date format. (I rather think the previous poster can be assumed to mean date format, as the given one is rather unsuitable for, say, floating point or currency).

  • (cs) in reply to Tuka
    Tuka:
    QJo:
    Either this is 7:15 pm, which means that they're both staying late, or they start *really early* in the morning.

    "pm" is a redundant information.

    No real programer starts before 9:00 am. And start means here "first coffee". So 7:15am is something which will never happen. The 'pm' can be dropped.

    Hmm, i start at 8:00 am, though maybe I'm not a real programmer since I don't have a CS degree.

  • (cs) in reply to solitario
    solitario:
    Tuka:
    QJo:
    Either this is 7:15 pm, which means that they're both staying late, or they start *really early* in the morning.

    "pm" is a redundant information.

    No real programer starts before 9:00 am. And start means here "first coffee". So 7:15am is something which will never happen. The 'pm' can be dropped.

    Hmm, i start at 8:00 am, though maybe I'm not a real programmer since I don't have a CS degree.

    I may get to the office by 8... but I don't start before 9... :)

  • (cs) in reply to operagost
    operagost:
    QJo:
    Of course, the *real* WTF is that both Jeff and Tabitha are working at 7:15. Which 7:15 it is, they don't say (another failure of the US way; the civilised world uses the 24-hour clock). Either this is 7:15 pm, which means that they're both staying late, or they start *really early* in the morning.
    The story says that Jeff was resigned to working after 5 PM, so clearly the most likely answer is 7:15 PM.

    By the way, we're "civilized."

    no you're not, you allow arseholes to carry guns even after it's shown to be piss-easy for a madman (of which you have far too manyt running around loose) to take a gun into a school and shoot loads of children - and then you don't do anything about it. That's not civilixed.

  • (cs) in reply to Ivan Godard
    Ivan Godard:
    The reason 13x28 day months are used in accounting (not just finance) is to make year-to-year results comparable. Without months being even modulo weeks there would be some years with a few percent more business days in them than others, leading to random variations in year-to-year (and month to month) results, which noise would swamp the signal of how the business is doing. It's GAAP. Before laughing at a non-techy, learn a bit about why it's done that way, and then see if you can figure out a better way. Harvard Business School would love to hear from you.

    Except that vehicle sales are wedded to the annual cycle - at least in the UK. August is when the new registration letter comes out, so there's a big spike in sales in August. And all days are business days now - no problem doing business on Sunday.

  • someone (unregistered) in reply to herby
    herby:
    Real programmers don't do work on times with single digits (using a 24 hour clock). They need rest somehow.

    I don't know about you, but I usually work at 1 AM

  • Wet Mastwood (unregistered) in reply to Matt Westwood
    Matt Westwood:
    you allow arseholes to carry guns even after it's shown to be piss-easy for a madman (of which you have far too manyt running around loose) to take a gun into a school and shoot loads of children - and then you don't do anything about it. That's not civilixed.
    Yeah, it is far better to disarm all the good people so the next megalomaniac madman politician can mow them down by the millions, like happened several times in "civilized" countries last century.

    Madmen are difficult to control. Rendering victims defenseless won't make the madmen suddenly sane.

    Nice troll, though.

    Oh, and you notice none of these madmen are quite insane enough to go shoot up a police station? Why might that be? Perhaps even a delusional schitzoid knows cops have guns and will shoot back in two seconds, making for a spectacularly brief terror campaign?

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered) in reply to Matt Westwood
    Matt Westwood:
    no you're not, you allow arseholes to carry guns even after it's shown to be piss-easy for a madman (of which you have far too manyt running around loose) to take a gun into a school and shoot loads of children - and then you don't do anything about it. That's not civilixed.
    That's mostly because of some 18th century arseholes with guns and red coats. And an arshole in charge of them with a throne on the other side of an ocean.
  • (cs) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    Matt Westwood:
    no you're not, you allow arseholes to carry guns even after it's shown to be piss-easy for a madman (of which you have far too manyt running around loose) to take a gun into a school and shoot loads of children - and then you don't do anything about it. That's not civilixed.
    That's mostly because of some 18th century arseholes with guns and red coats. And an arshole in charge of them with a throne on the other side of an ocean.

    I'm not sure if I've stated this before, but you're my favorite commenter on this site.

  • emaNrouY-Here (unregistered) in reply to Wet Mastwood
    Wet Mastwood:
    Matt Westwood:
    you allow arseholes to carry guns even after it's shown to be piss-easy for a madman (of which you have far too manyt running around loose) to take a gun into a school and shoot loads of children - and then you don't do anything about it. That's not civilixed.
    Yeah, it is far better to disarm all the good people so the next megalomaniac madman politician can mow them down by the millions, like happened several times in "civilized" countries last century.

    Madmen are difficult to control. Rendering victims defenseless won't make the madmen suddenly sane.

    Nice troll, though.

    Oh, and you notice none of these madmen are quite insane enough to go shoot up a police station? Why might that be? Perhaps even a delusional schitzoid knows cops have guns and will shoot back in two seconds, making for a spectacularly brief terror campaign?

    Exactly. With the exception of one instance, all shootings that involved more than 3 people have occurred in "gun free" zones.

  • Mike (unregistered) in reply to Valued Service

    It will be a cold day in July in New York when we switch back to the lunar calendar... well about 728 years later... sorry.

  • Valued Service (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    Valued Service:
    Dom:
    Surely the "human system for reckoning time" is based on the Earth's rotation and its orbit around the Sun. Maybe the blame lies with God.

    The problem is that the rotation around the sun doesn't occur at an exact number of earth's rotations. Which means that every year occurs within 365.xx days. That little xx is what causes our years to have extra days in them.

    We try to fit in those extra days by blowing up that fraction until we have how many days per set of years. But the fraction is so precise that we can't use filler days with any degree of sanity. Plus, we don't have a precise calculation for that fraction, so we find out every now and then we're off by an hour or so.

    Because we like base 10 so much, instead of adding days per x years. We add 1 day per 4 years except every 100 years except every 1000 years. So 1700, 1800, 1900 not a leap year, but 2000 is.

    This is all because we prefer our years to land on solar dates.

    We could of course switch back to a lunar calendar.

    (hat type="pendant" position="on head") The Earth revolves around the Sun, and rotates on its axis, so it is "revolutions" and "rotations".

    And it is one leap year per four years, except every hundred years, except every 400 years. (Technically, every century year before 1600 was a leap year because the Gregorian calendar that introduced the except-100-exceptsquared-400 rule wasn't invented until after 1500.) (/hat)

    Yeah, screwed that one up.

    Just goes to show how confusing it is.

    That's 97 leap years in 400 years.

    Can't really think of a better way to arrange that.

  • Abico (unregistered)

    TRWTF is why it took over two hours to find the code that sets the date.

  • Valued Service (unregistered) in reply to emaNrouY-Here
    Matt Westwood:
    you allow arseholes to carry guns even after it's shown to be piss-easy for a madman (of which you have far too manyt running around loose) to take a gun into a school and shoot loads of children - and then you don't do anything about it. That's not civilixed.

    Wait... rewind... backup. There, you see it?

    "... for a madman (of which you have far too many running around loose)..."

    When you boil down your argument, it isn't against guns. It's against madmen having guns. And you reason that happens because they're running loose.

    How about some more logic for you.

    Most gun deaths are not from mass shootings. They're single homicides, of which most of those are caused by early parole with multiple prior homicides.

    So, the real problem is letting all these madmen back onto the streets.

    Gun control is an item, because liberal politicians are truly frightened that eventually conservative backlash will turn violent. They know they're forcefully stripping our rights, and want to curtail our options for explosive retribution. If you think that's lunacy, how about that notice that leaked to the public warning congress about extreme radicals from the south and retired military posing a threat to national security, because they have experience with firearms.

  • xargs (unregistered)

    I don't know this language, but isn't there a race condition on multiple invocations of DateTime.Today?

  • urza9814 (unregistered) in reply to Valued Service
    Valued Service:
    Gun control is an item, because liberal politicians are truly frightened that eventually conservative backlash will turn violent. They know they're forcefully stripping our rights, and want to curtail our options for explosive retribution. If you think that's lunacy, how about that notice that leaked to the public warning congress about extreme radicals from the south and retired military posing a threat to national security, because they have experience with firearms.

    That report was about dangers posed by right-wing extremists. Like Timothy McVeigh. It's just been taken as a call to arms by people who like to claim that only brown Muslims can possibly be terroroists.

    And there's just as much chance that the armed rebellion will come from the left as the right. Anarcho-syndicalists glorify their right to bear arms just as much as Anarcho-capitalists. That's not a left vs. right issue, it's an authoritarian vs. libertarian issue. Completely different axis.

  • Joe (unregistered) in reply to F
    F:
    urza9814:
    Pock Suppet:
    Urong. The only format any programmer should ever use is yyyy-mm-dd. Period.

    What about SSSSSSSSSS?

    That's a time format, not a date format. (I rather think the previous poster can be assumed to mean date format, as the given one is rather unsuitable for, say, floating point or currency).

    In keeping with the VB theme, the date format should be DDDDDDDDDDDDDD.DDDDDDDDD (approximately, depending on your floating-point representation) of usually the number of days since December 31, 1899. It would have been since Jan 1 1900, but 1900 wasn't a leap year, so dates less than 59 are wrong.

    --Joe

  • Simon (unregistered) in reply to Tuka
    Tuka:
    No real programer starts before 9:00 am. And start means here "first coffee". So 7:15am is something which will never happen. The 'pm' can be dropped.

    That's the words of someone who's never worked a 24 hour day, never had co-workers arrive in the morning and say "you're here early"...

  • (cs)

    The "algorithm" in the OP's code reminds me of the calendaring system in ON/2, a financial transaction package I once had the "pleasure" of working with. Everything, including the calendar, was driven from tables.

    On first glance, this must have seemed like a good idea to someone. If you want to institute a five-day holiday, you simply set up your calendar so that the day after January 25 is January 30. Takes care of weekends, business closings that fall on a different date each year, funky local holidays, etc, all in a completely configurable form.

    The downside arises when someone forgets to set up the entries for the next month's calendar. All of a sudden, transactions fail because they can't figure out when "tomorrow" is.

  • Worf (unregistered)

    If you wanted to roll your own date library... look at these misconceptions first when designing.

    http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time

    Part 2 http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time-wisdom

    Heck, I think the world runs on Microsoft Outlook time - the only reason people end up knowing when meetings are is because Microsoft's kept bug-for-bug compatibility with the time and date of the meeting. It may be completely wrong, but if most people use Outlook and get it right, it's official.

  • David Jackson (unregistered) in reply to Matt Westwood
    Matt Westwood:
    Ivan Godard:
    The reason 13x28 day months are used in accounting (not just finance) is to make year-to-year results comparable. Without months being even modulo weeks there would be some years with a few percent more business days in them than others, leading to random variations in year-to-year (and month to month) results, which noise would swamp the signal of how the business is doing. It's GAAP. Before laughing at a non-techy, learn a bit about why it's done that way, and then see if you can figure out a better way. Harvard Business School would love to hear from you.

    Except that vehicle sales are wedded to the annual cycle - at least in the UK. August is when the new registration letter comes out, so there's a big spike in sales in August. And all days are business days now - no problem doing business on Sunday.

    Err not since 2001. The new registrations come out on 1st March and 1st September.

  • (cs)

    properly handling dates? ain't nobody got time fo dat!

  • Paul Neumann (unregistered) in reply to fjf
    fjf:
    Ivan Godard:
    The reason 13x28 day months are used in accounting (not just finance) is to make year-to-year results comparable. Without months being even modulo weeks there would be some years with a few percent more business days in them than others, leading to random variations in year-to-year (and month to month) results, which noise would swamp the signal of how the business is doing. It's GAAP. Before laughing at a non-techy, learn a bit about why it's done that way, and then see if you can figure out a better way. Harvard Business School would love to hear from you.
    How about comparing results per time unit rather than absolute results (like they do in physics with power and various other quantities)? That would also take care of holidays. Do they teach division at business schools?
    Brillant! You've solved it!! We can throw out all those books on GAAP.

    What sort of fixed period do you suppose we should use? We can't be too fine grained or else the static will overpower any stats, so single weeks are out. We can't just average the full year because that will filter out our stats.

    What's that? 28 days? Why yes, that would keep the weekend days consistant between sets and gives us a very near approximation to OTHER calendars.

    Perfect. fjf has solved the GAAP problems. Everyone throw away your GAAP manuals and simply move to using a fixed 28 day cycle instead. There may be a few quirks to iron out, but I'm sure it will be much better than GAAP!

  • Horse (unregistered)

    Given Tabatha's reaction, clearly either she wrote the code, or she was so high in the food chain she had no chance of understanding it.... Lesson: When you need a second opinion, don't ask a superior (in fact try to ask at level - asking downward might cop people who just want to agree with you)

  • sg4r (unregistered) in reply to QJo
    QJo:
    Karma:
    Of course, if the human system for reckoning time is so thoroughly hosed that 99 out of 100 programmers can't implement it, is there any chance some of the blame might lie with the human system for reckoning time?

    Absolutely not. The ability to handle the really-quite-straightforward technique for reckoning time according to the Gregorian calendar is a pons asinorum in the understanding of the universe. And if there are computer programmers who do not have the basic intelligence to be able to understand how a calendar works, they have absolutely no business being in the industry.

    What's the current socio-political position as regards eugenics and euthanasia for the terminally thick?

    Euuuu

  • dJim (unregistered) in reply to QJo
    QJo:
    Of course, the *real* WTF is that both Jeff and Tabitha are working at 7:15. Which 7:15 it is, they don't say (another failure of the US way; the civilised world uses the 24-hour clock). Either this is 7:15 pm, which means that they're both staying late, or they start *really early* in the morning.
    Nit wit. The line above talks about working after 5PM. So it's either 19:15 or he worked all through the night

    Either way, I'm surprised a supervisor would still be there for a minor issue (there's only 3 tickets not 18, remember?)

  • Mick (unregistered) in reply to Frank
    Frank:
    Pock Suppet:
    The only format any programmer should ever use is yyyy-mm-dd. Period.
    QFT. If you disagree, you are Wrong. Very Wrong. Sorely Wrong. Perhaps Incurably Wrong. Reboot your brain and read again: The only format any programmer should ever use is yyyy-mm-dd. Period.
    Don't like your separators. Prefer YYYYMMDD
  • Jeremiah (unregistered) in reply to Remy Porter

    VB.Net combines the power of QBasic and the clarity of Pascal.

  • fjf (unregistered) in reply to Paul Neumann
    Paul Neumann:
    fjf:
    Ivan Godard:
    The reason 13x28 day months are used in accounting (not just finance) is to make year-to-year results comparable. Without months being even modulo weeks there would be some years with a few percent more business days in them than others, leading to random variations in year-to-year (and month to month) results, which noise would swamp the signal of how the business is doing. It's GAAP. Before laughing at a non-techy, learn a bit about why it's done that way, and then see if you can figure out a better way. Harvard Business School would love to hear from you.
    How about comparing results per time unit rather than absolute results (like they do in physics with power and various other quantities)? That would also take care of holidays. Do they teach division at business schools?
    Brillant! You've solved it!! We can throw out all those books on GAAP.

    What sort of fixed period do you suppose we should use? We can't be too fine grained or else the static will overpower any stats, so single weeks are out. We can't just average the full year because that will filter out our stats.

    What's that? 28 days? Why yes, that would keep the weekend days consistant between sets and gives us a very near approximation to OTHER calendars.

    Perfect. fjf has solved the GAAP problems. Everyone throw away your GAAP manuals and simply move to using a fixed 28 day cycle instead. There may be a few quirks to iron out, but I'm sure it will be much better than GAAP!

    Who said anything about a fixed period? I explicitly made the comparison to physical units. You can convert them as needed, e.g. you can measure speed in meters per second, inches per fortnight or light years per year, it doesn't matter.

    I'm no accounting expert and I don't know what else GAAP is meant to do (BTW, typed "gaap" (without the upper case) into Wikipedia and got "In demonology, Gaap is a mighty Prince and Great President of Hell ..." :). I was just replying to what Ivan Godard said, to make results comparable. That's easy with result per time unit. If there are other issues to be solved, why don't you mention them instead of getting sarcastic?

  • anonymous (unregistered) in reply to Pock Suppet

    Doesn't work by default in Oracle. But then again Oracle is shit.

  • Paul Neumann (unregistered) in reply to fjf
    fjf:
    Who said anything about a fixed period? I explicitly made the comparison to physical units. You can convert them as needed, e.g. you can measure speed in meters per second, inches per fortnight or light years per year, it doesn't matter.
    Right, except the whole point is to be able to compare cyclic similarities and differences.

    Comparing Sales per Hour for 16:00 - 18:00 (local time) on a Friday in summer to 04:00 - 06:00 (local time) on a Sunday morning in dead winter will be useless. Even if you convert them to sales per week. Even if you convert them to sales per second.

    The point (which you've splendidly reinforced (again)) is that unless you understand the domain of a problem, you cannot refactor the problem to suit your preferences.

    I'm no accounting expert and I don't know what else GAAP is meant to do (BTW, typed "gaap" (without the upper case) into Wikipedia and got "In demonology, Gaap is a mighty Prince and Great President of Hell ..." :).
    Pretty sure the Gods of accounting did that on purpose.
    I was just replying to what Ivan Godard said, to make results comparable. That's easy with result per time unit. If there are other issues to be solved, why don't you mention them instead of getting sarcastic?
    OMG, 4eAL, SRSLY?? Have you been here long? Here's some charity.

  • Meep (unregistered) in reply to chubertdev
    chubertdev:
    Pock Suppet:
    Urong. The only format any programmer should ever use is yyyy-mm-dd. Period.

    Wrong, date formatting is for the UX guys. :)

    Don't entirely agree... an API should use ISO 8601 because it's unambiguous. If you send Julian dates, you're pretty much guaranteeing someone will get the wrong epoch.

    That said... even with ISO8601, people have problems munging the damned time zone, and as recently as Java 6 (!!) the standard libraries couldn't handle timezones correctly, and if you forget to specify the timezone to the parser it just ignores it and everything looks correct.

Leave a comment on “De-Populate Dates”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article