• (disco) in reply to accalia

    Oh, by all means, do carry on.

    Besides, I do not think such things are in my power.

  • (disco) in reply to Onyx

    and i can't even stay angry at you for it..... well played good sir. well played.

    :slow_clap.wmv:

  • (disco) in reply to accalia
    accalia:
    Julian Dates

    don't help with appointment times.

    If I've booked a doctor's appointment for 3:15pm on some particular date, then I expect the doctor to expect me at 3:15pm on that date, regardless of whether daylight saving kicks in or out on a different day from what was anticipated when the appointment was recorded.

    That means that it is not safe to convert the appointed time to an offset from some epoch, or even a minute offset from the start of some Julian day, because there is never any guarantee that Daylight Saving rules will not change between the time the appointment is recorded and the time of the appointment itself.

  • (disco) in reply to flabdablet
    flabdablet:
    don't help with appointment times.

    It does, but you have to handle those carefully. In particular, the time has to be resolved with respect to the rules in place for that day and that timezone locale. There's a good reason why ISO timestamps and durations are expressed the way they are: anything else less complex is not going to work in the real world.

    But you still use julian days and unix epochs for calculations. :smile:

  • (disco) in reply to dkf

    I believe his point is on the real world thing and changing legislations: If I've got a dentists' appointment at 10:00 on 3 July, I can't store that as 2015/07/03T10:00:00+02:00, or as 2015/07/03T10:00:00 CEST. I must instead specify 2015/07/03T10:00:00 Europe/Amsterdam, to account for the fact the Netherlands may (independently from the rest of western Europe) change DST rules between now and then.

  • (disco) in reply to PleegWat
    PleegWat:
    to account for the fact the Netherlands may (independently from the rest of western Europe) change DST rules between now and then.

    But that doesn't take into account the fact that mysterious aliens may decide to make the Earth spin faster between now and then so that days are less than 10 hours long. What will you do in that case? (I hate stupidly unlikely hypothetical situations.)

  • (disco) in reply to dkf

    Didn't say I agreed with him. And although I do believe countries have changed their DST rules on short notice in the past, that likely still gives you a couple months to roll-out patch scripts to affected customers. And it's affect practically everyone, except maybe @flabdablet's customers, and anyone whose systems actually only store localtime.

  • (disco) in reply to dkf
    dkf:
    Really? I don't mean to doubt what you say, but that would be the sort of fuckup that you don't usually see in Perl, due to its widespread use by pedantic asshole sysadmins…
    *Errr...*

    I am not quite sure what your are asking? It is there in the post:

    my $year = (localtime)[5] + 1900;
#...
my $month = (localtime)[4] + 1;
#...
my $day = (localtime)[3];
#...    
my $hour = (localtime)[2];
#...    
my $min = (localtime)[1];
#...    
my $sec = (localtime)[0];

    The get_timestamp subroutine calls localtime() 6 separate times, once for each date element.

  • (disco) in reply to anonymous_coder
    anonymous_coder:
    We handle it by not scheduling any batch jobs between 11 PM and 12:15 AM. Seriously.
    **!**

    I wish I could say I am horrified and shocked beyond all belief... What about the hour and minute roll overs?

  • (disco) in reply to groz

    it's accounting. they don't care about anything less than day resolution.

  • (disco) in reply to groz

    Ah, I went back and reread the article. @groz is indeed correct.

    groz:
    dkf:
    Really? I don't mean to doubt what you say, but that would be the sort of fuckup that you don't usually see in Perl, due to its widespread use by pedantic asshole sysadmins…
    The `get_timestamp` subroutine calls localtime() 6 separate times, once for each date element.
    To clarify, `get_timestamp` is not a Perl library function that would be in "widespread use by pedantic asshole sysadmins;" it's the WTF in the article. It does, indeed, call `localtime` 6 times.

    The WTF includes not only roll-your-own date handling, but inefficiency and vulnerability to date and/or time roll-over while fetching the date and time multiple times.

  • (disco) in reply to dkf
    dkf:
    In particular, the time has to be resolved with respect to the rules in place for that day and that timezone locale.

    The point is that any such resolution performed before the appointed date opens the possibility that a subsequent change in DST rules will make the resolved time wrong. Simply storing the appointment date and time as entered does not.

    DST rules are subject to political whim and not necessarily predictable in advance.

  • (disco) in reply to PleegWat
    PleegWat:
    And although I do believe countries have changed their DST rules on short notice in the past, that likely still gives you a couple months to roll-out patch scripts to affected customers.
    The linked Computerphile video described an occasion where one country (IIRC it was Libya) decided to not do DST with only a few days' notice.

    In my state, I've already lived though a couple of iterations of "we're going to do DST for a few years, then we'll have a referendum, oh, the referendum said people didn't want it so we'll stop." So far it's been defeated by referendum four times - I'm sure we'll be trialling it again in another 10 years or so.

  • (disco) in reply to HardwareGeek
    HardwareGeek:
    it's the WTF in the article

    Don't read that; you'll start to think this place is slashdot…

  • (disco) in reply to Scarlet_Manuka
    Scarlet_Manuka:
    So far it's been defeated by referendum four times - I'm sure we'll be trialling it again in another 10 years or so.

    Next up is splitting up the state so that the areas that "want it" will get it and the others don't.

    I don't want DST. I used to like going for a swim in the surf before work. Taking that hour means there won't be enough time!

  • (disco) in reply to Zemm

    Also, it fades your curtains.

  • (disco) in reply to RaceProUK

    If that MaxDate code is .Net, then it's got a serious problem : DateTime.Date is read-only

  • (disco) in reply to flabdablet
    flabdablet:
    If I've booked a doctor's appointment for 3:15pm on some particular date, then I expect the doctor to expect me at 3:15pm on that date
    You expect to be stepping into a doctor’s office at the time of your appointment with that doctor? What country do you live in, that has doctors who have learned to schedule appointments so that they don’t run long and force everyone coming after to wait even longer than they expected to?
  • (disco) in reply to Gurth
    Gurth:
    What country do you live in, that has doctors who have learned to schedule appointments so that they don’t run long and force everyone coming after to wait

    That's not what he said. The doctor expecting you at a specified time is not the same as the doctor being ready for you at a specified time. Ideally, the former would imply the latter, but as you pointed out, that rarely happens.

  • (disco) in reply to Gurth
    Gurth:
    You expect to be stepping into a doctor’s office at the time of your appointment with that doctor? What country do you live in, that has doctors who have learned to schedule appointments so that they don’t run long and force everyone coming after to wait even longer than they expected to?

    What amazes me is how they're even 15+ minutes late on the first or second appointment of the morning

  • (disco) in reply to HardwareGeek
    HardwareGeek:
    That's not what he said. The doctor expecting you at a specified time is not the same as the doctor being ready for you at a specified time.
    He didn’t say that, true, but I doubt the doctor, while dealing with one patient, will be looking at the clock, see it’s a quarter past three and think, “Oh, I need to hurry up, I’m expecting flabdablet.” More likely, I think, is that the doctor only sort of keeps an eye on the time, taking overruns for granted, and hasn’t got a clue who’ll be coming in next.
  • (disco) in reply to Gurth

    That is true. However, the doctor's staff knows who is due, and when. Remember the context — being off by an hour due to a DST change. If you're an hour earlier than they expect you (even if that's because their expectation is wrong due to the scheduling system mishandling the DST change), you won't get to see the doctor earlier than you would by arriving when expected. If you arrive an hour late, you will likely find your appointment cancelled; if it was due to their own scheduling error, maybe you can persuade them not to charge you for the visit anyway (which in the US your insurance probably won't cover) as a no-show.

  • (disco) in reply to Gurth
    Gurth:
    He didn’t say that, true, but I doubt the doctor, while dealing with one patient, will be looking at the clock, see it’s a quarter past three and think, “Oh, I need to hurry up, I’m expecting flabdablet.”

    But the people working at the front desk of his office probably will be wondering where he is.

  • (disco) in reply to Gurth

    Also,

    Gurth:
    I doubt the doctor, while dealing with one patient, will be looking at the clock, see it’s a quarter past three and think, “Oh, I need to hurry up, I’m expecting flabdablet.” More likely, I think, is that the doctor, **while dealing with one patient, will be looking at the clock, see it’s a quarter past three and think, “Oh, I need to hurry up, *I have a 4-o'clock tee time*.”**
    FTFG
  • (disco) in reply to accalia
    accalia:
    reads to me more like he has and doesn't trust it.

    People like that shouldn't be let near a keyboard.

    "I don't trust the database's transaction system, so I'll write my own manual one that involves querying a set of records, copying them into a set of temp tables with matching definitions, doing all my work on the temp tables, and then at the end calling a procedure that copies the temp-table records back into he database."

    This was in an application responsible for ~$10M dollars in revenue a month.

  • (disco) in reply to VinDuv
    VinDuv:
    Also, regex abuse. Perl has a function to get the length of a string; it’s called length. It also has a sprintf function to avoid having to manually prepend zeros.

    Regex abuse is a serious matter. I've seen whole families torn apart by years of relentless pattern matching and noncapturing groups.

  • (disco) in reply to nerd4sale
    nerd4sale:
    Any sane language has a date type

    JavaScript also has one.

  • (disco) in reply to tar
    tar:
    I've seen whole families torn apart by years of relentless pattern matching and noncapturing groups.
    Not to mention lookbehinds and possessive quantifiers!
  • (disco) in reply to tar

    The statement sane languages have date types does not imply unsane (insane? non-sane?) languages do not have date types.

    It is, however, equivalent with the statement a language without a date type isn't sane.

  • MarilynRexum (unregistered)

    What necessary words... super, remarkable idea

    circumspection shiny pantyhose bondage

  • Eddiegah (unregistered)

    https://waylonxpix00332.blog5.net/47032801/Онлайн-девушки-из-твоего-города актив вебкам бесплатно https://fernandozqhw99876.life3dblog.com/8691597/Бесплатный-вебкам-сайт бесплатные игры с вебкой http://kameronfzqg33211.bloggosite.com/10448658/Бесплатный-вебкам-секс как установить вебку бесплатно https://alexisrkbr71100.blog5.net/47040933/Бесплатный-чат бесплатный секс вебкам чат бесплатная вебка знакомства вебкам онлайн бесплатный чат [url=https:/

Leave a comment on “Dating Woes”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article