cant we already get to a point where we have one single fat datetime format in CS...

ISO this, RFC that, UNIX those

  • 11
    Unix or ISO8601

    Anything else and I'll keeel you.
  • 7
    @C0D4 keelhaul that filthy mm/dd/yy-er
    Send him down to the depths below
  • 0
    @RememberMe bloody Americans 😔 even when they have standards, they go and make their own.
  • 3
    I swear to God fuck everything except dd/mm/yyyy
  • 0
    dd/mm/yyyy for human-readable dates.
    yyyy/mm/dd for human-readable time-stamps.
    Unix for non-human-readable timestamps.
  • 0
    @Ranchu don't you mean dd-mm-yyyy
    I can live with that but it's still stupid.

    A number 123.45 has the opposite significance. We all know that yyyy-mm-dd sorts well. But don't forget that we hate the American date because it has mixed significance; when we take dd-mm-yyyy and add time it's going to be dd-mm-yyyy hh:mm:ss. Mixed fucking significance again. Good luck sorting that.
  • 0
    @metamourge yyyy-mm-dd for human readable dates. It's just the one that makes the most sense and actually readsb the best especially with time added
  • 1
    @hjk101 honest opinion? Preference hereby is based upon what one was raised with.
  • 1
    ISO, it's frontend problem to localize style how to display.
  • 1
    @Ranchu Americans do it so messed up because they say it like 26th of may 2020. I did grow up with dd-mm-yyyy but it's still technically less readable than yyyy-mm-dd.

    But sure you train your mind and if you have been doing it your whole life it becomes effortless. Just look at how many people think binary or hex can never be comprehended. Yet they use a mixed base system like time.
  • 1
    Store dates where time is known (and matters) as
    ISO 8601 timestamps in UTC 2020-05-26T10:33:58Z no matter what the users timezone convert to UTC. Convert it back to the users locale for display. Make sure to store the users time zone somewhere (not EST but America/New_York so DST calculations can happen via your time lib). Storage of a time zone with your user (or somewhere) is important so you can convert back for things like reports and downloads where you don’t have the benefit of the user’s computers time zone.

    For dates that don’t care about time. Birthdays, store YYYY-MM-DD. For display once again convert to what ever the users locale calls for on front end.

    After years of API design for a national platform with customers across America this is the only way to stay sane.
Add Comment