• Labasta (unregistered)

    Heh! Cute.

  • Hanzito (unregistered)

    Sometimes children ask what good it does to go to school. I have maps on my phone. Do I need geography? It has a calculator. For what do I need to study maths?

    Well, if you don't want to end up on the DailyWTF, pay attention, kids.

  • Jan (unregistered)

    The code is not anonymized, so it's easy to find out what it is. It's dojo DatePicker.

  • Don't write your own date functions (unregistered)

    Don't write your own date functions!

  • Nick (unregistered)

    “Don’t write your own date functions” they said… “Use a library” they said… and what do we have here? A WTF in the library we chose to use!

    I quit

  • LZ79LRU (unregistered)

    I firmly disagree. Everyone should try and write their own date and time handling libraries at least once in life. It's a fun project, a good learning experience and most importantly it will teach you the value of using standard libraries.

    But like... don't do it in production.

  • Hanzito (unregistered) in reply to LZ79LRU

    Apparently, another lesson is: don't pick a bad library either. But do you distinguish between good and bad libraries if you've never tried it yourself?

  • Foo AKA Fooo (unregistered) in reply to Nick

    I hear your sarcasm, but it's a valid point. "Use a library" by itself is not good advice. Anyone can take some code and slap a library label on it (left-pad anyone?). Using good libraries is key.

    I've found myself in the situation of using a library which wasn't terrible, but not great, and after coming a few problems and getting no support, I realized what I actually used of the library (and didn't have elsewhere in similar form) was about 20 lines of code. That was my signal to drop that library.

  • (nodebb) in reply to Foo AKA Fooo

    I realized what I actually used of the library (and didn't have elsewhere in similar form) was about 20 lines of code. That was my signal to drop that library.

    The reason this doesn't happen more often is due to the costs and benefits of a library not being borne by the same party.

    In the common and naïve development model, using a library is "good" and writing your own common function is "bad". End of discussion. In this models, all of the costs of using the library are borne by the users of the application, not the developers. There is a feedback loop where the users get angry at the developers, but everyone feels wronged and little is done to make the situation better.

    In a more mature development model where the development team bears the cost of researching the library's code quality history and practices and updating the application to a new version of the library when a defect is fixed (or at least testing the application when the library is updated at all), will cause a development team to not consider using a library with a scope too large or a library with a poor reputation. In this model, including a library has real costs and the development team is unlikely to ever use a library for "left pad", and will tend to use a mature and appropriate library for date functions.

  • Randal L. Schwartz (github)

    I realize this isn't the usual timezone snafu, but I'm inspired to google that computerphile tom scott classic: https://youtu.be/-5wpm-gesOY

  • (nodebb)

    {Everyone should try and write their own date and time handling libraries at least once in life.} This. I had to (try)do it as part of learning S370 ASM. It did teach me to not write my own date handler.

  • LZ79LRU (unregistered) in reply to Hanzito

    Generally speaking the closer a library is to being integrated into the languages standard library of functions the better it is. Generally. All rules have exceptions.

  • Alex (unregistered)

    "starting day of the week- which might be a day other than Sunday" - might? MIGHT? Week starts on Monday ;)

  • Martins (unregistered)

    The real WTF is starting the week on any day that isn't Monday

  • Brian Boorman (unregistered) in reply to Martins

    Right - because your culture and preferences are obviously the only correct ones.

  • LZ79LRU (unregistered) in reply to Martins

    I agree. With mondays you get a week nicely split into two segments. The working part and the leisure part. It's just sensible to do it that way. And any other way just isn't.

  • WTFGuy (unregistered)

    As to the advice to write your own date/time handling libraries as a learning experience. ...

    Would be good if the developer in question bothered to learn anything about human date and time handling first. The usual problem isn't that folks get their code wrong, it's that their code doesn't handle the hundreds of edge cases the developer was utterly unaware even existed. Daylight savings time? half-hour offset time zones? Leap seconds? Different calendars? etc. etc. etc. And of course they end up designing their code so the edge cases can't easily be retrofitted.

    By the time somebody knows enough about human calendars and clocks to actually write a useful datetime library, they'll be enough of a SME to not need to do it anymore.

  • Argle (unregistered) in reply to LZ79LRU
    Comment held for moderation.
  • Argle (unregistered) in reply to WTFGuy
    Comment held for moderation.
  • löchlein deluxe (unregistered)

    I think the pythonic solution would probably be something along the lines of (DAYS+DAYS)[startDay:] and now I need a stiff one.

  • Drak (unregistered) in reply to Brian Boorman
    Comment held for moderation.
  • LZ79LRU (unregistered) in reply to WTFGuy

    Which you must admit is a learning and humbling experience in its own right. And a greater lesson all developers, and indeed all people could use.

  • Erin (unregistered) in reply to LZ79LRU
    Comment held for moderation.
  • (nodebb) in reply to Brian Boorman

    Right - because your culture and preferences are obviously the only correct ones.

    Well, ISO 8601 agrees with him.

  • Someone (unregistered) in reply to LZ79LRU

    I was asked to write some date handling code during a job interview. It worked pretty well as a way to see programmers deal with corner cases. The code did not work, but interview code rarely does.

Leave a comment on “A Modular Week”

Log In or post as a guest

Replying to comment #:

« Return to Article