Amazon is running a Prime Day sale on July 16 and 17. Setting aside the fact that this is two separate days, neither 716 nor 717 are prime numbers. They should’ve done 7/19 instead.

  • hddsx@lemmy.ca
    link
    fedilink
    arrow-up
    39
    arrow-down
    9
    ·
    4 months ago

    I maintain that dd/mm/yyyy and mm/dd/yyyy are stupid.

    Big -> small is how we read numbers:

    yyyy/mm/dd

    • Old Jimmy Twodicks@sh.itjust.works
      link
      fedilink
      arrow-up
      48
      arrow-down
      1
      ·
      4 months ago

      I prefer the simple dy/my/dy/my format (with the year reversed for added ease of use). For example, today would be 14/02/70/72.

      NIST and ISO have stopped responding to my emails, but I’m optimistic that the Türk Standardları Enstitüsü will eventually adopt it as their preferred standard.

    • Nurse_Robot@lemmy.world
      link
      fedilink
      arrow-up
      17
      arrow-down
      3
      ·
      4 months ago

      Yeah, but you have to admit mm/dd/yyyy is way more stupid. Small -> big makes more sense than middle -> small -> big

      • hddsx@lemmy.ca
        link
        fedilink
        arrow-up
        6
        ·
        4 months ago

        For every day purposes, absolutely. For programming? Nope, the only right answer is big->small.

        Honestly, the alternative to every day use is to stop using numbers for the month

      • booly@sh.itjust.worksOP
        link
        fedilink
        arrow-up
        1
        ·
        4 months ago

        Actually, I disagree that DD/MM/YYYY even qualifies as being small to big.

        If you actually treat it as a counter from 01/01/2024 onward, note that the first digit that moves is actually the second digit in the 8-digit representation. In terms of significance, the most significant digit is the 5th one in the string, then counting down the significance it’s 6th, then 7th, then 8th, then jumps back to the 3rd, then the 4th, then the 1st, then the 2nd.

      • Zorque@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        arrow-down
        1
        ·
        edit-2
        4 months ago

        12 is smaller than 31 is smaller than ∞, though.

        Really, we can all come up with vastly reasonable reasons the date system we prefer makes the most sense… but in reality it’s all very subjective. Not only will different methods be appropriate for different situations… but some people just prefer their own way.

        It’s all really moot, though. We should have been using stardates for the last 55 years anyways.

    • booly@sh.itjust.worksOP
      link
      fedilink
      arrow-up
      5
      arrow-down
      1
      ·
      4 months ago

      Yes, and recurring dates naturally drop the year, so MM/DD better fits that general rule.

    • esc27@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      edit-2
      4 months ago

      What if we just count all the nanoseconds since 1601 and divide by 100.

      I still don’t get that timestamp approach. Especially after learning how unix/linux handle it…

      At least modern AD tools can automatically do the date conversions now.

      • hddsx@lemmy.ca
        link
        fedilink
        arrow-up
        1
        ·
        4 months ago

        Because it’s a basic data structure that holds time, instead of multiple interrelated ints…. And it’s easy to do math on.

    • some_guy@lemmy.sdf.org
      link
      fedilink
      arrow-up
      2
      arrow-down
      1
      ·
      4 months ago

      ^^ This is the only acceptable way to write out the date numerically. I’ll die on this hill.

    • Fubber Nuckin'@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      4 months ago

      Yes but small is more relevant since you’re more likely to know the big. therefore i propose we put minutes ahead of hours.

      • hddsx@lemmy.ca
        link
        fedilink
        arrow-up
        1
        ·
        4 months ago

        Big is more important than small. If your use case has the big stuff in context, drop the big.