660
The perfect date (thelemmy.club)
submitted 3 weeks ago by to c/lemmyshitpost@lemmy.world
239 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 322 points 3 weeks ago (35 children)

ISO 8601

  • permalink
  • fedilink
  • source
  • hideshow 43 child comments
    •
  • [–] 201 points 3 weeks ago (7 children)

    ISO 8601

    YYYY-MM-DD

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 13 child comments
    •
  • [–] 16 points 3 weeks ago (2 children)

    RFC 3339 FTW!

    Open source, and no ambiguous options grandfathered in.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 5 points 3 weeks ago

    Was looking for this. Yes. Whenever possible, dates should be specified in a format that is BOTH RFC 3339 and ISO 8601. I'd say both have their quirks, but the intersection of the grammars is machine-parseable and human-readable without (much) legacy baggage or (much) experimental / reserved-for-future-use noise.

  • permalink
  • fedilink
  • source
  • parent
    • load more comments (1 reply)
    • load more comments (1 reply)
  • [–] 63 points 3 weeks ago (2 children)

    As for why it's better:

    1. It's in sort order. Even if you use it for things that don't understand dates, they sort properly because the day is the last part, month is the middle part, and year is the first part. If you include hours, minutes or seconds, the sort order is still preserved.
    2. Speaking of things that don't understand dates, because there are no slashes, you can easily use it in file names, directories, and anything else that treats slash as a special character. In addition, if you include the time part, because it uses "T" to separate the date and time, it doesn't use a space, so once again it can be easily used anywhere where a space might cause issues.
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 10 points 3 weeks ago (2 children)

    ISO is better for archiving and sorting, inarguably so. But dd-mm-yyyy is better for day to day daily life usage, where the day and month are much more important than the year.

    Both have their uses, but for different situations. mm-dd-yyyy is just batshit though.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
    • load more comments (1 reply)
  • [–] 5 points 3 weeks ago (1 child)

    To be fair, the time separators don't behave well on all implementations of filesystem access by filename. Need to use underscores or omit them at times.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 3 weeks ago* (last edited 3 weeks ago) (1 child)

    And unlike most „forbidden characters“ for file names, the colon is actually used in NTFS: to separate the file path from the name of a named fork Alternate Data Stream.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 13 points 3 weeks ago (2 children)

    ISO would be great, but sadly OmegaStar doesn't support ISO timestamps yet.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 13 points 3 weeks ago (2 children)

    Wtf is an omega star?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
    • load more comments (1 reply)
  • [–] 4 points 3 weeks ago (4 children)

    Except I can't get behind the time part of it, personally. I can see the point of doing GMT with the offset if you're working across multiple timezones, but it's overkill for situations where you aren't.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 7 points 3 weeks ago* (2 children)

    That’s how my brother missed a train: the linux planner used GMT while the local train company planner used assumed local time…

    So I disagree

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 3 points 3 weeks ago

    I think we should all, as a globe, just pick one time zone and use that. I don't care if my 1:00 pm is the middle of that night. Everyone's 5:00pm will be 5:00pm. We will learn how to adjust our schedules for the master time zone.

  • permalink
  • fedilink
  • source
  • parent
    • load more comments (1 reply)
  • [–] 3 points 3 weeks ago (1 child)

    How so, out of curiosity?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 3 weeks ago (1 child)

    If you work at a company where all of its offices are in the same time zone and you're time-stamping logs, then it's more expedient for understanding and placing an event in time against other things to use local time.

    Unless everything is already standardized as GMT with offset I guess, but I feel like down that route lies madness.

    "I got your email at 20:37:45-7:00" is a few more steps than "I got your email at 1:37PM".

    It's not a big hurdle, but I try to design for the newest member on the team scrambling in panic rather than a calm cool professional already familiar with conventions.

    Now, as soon as we do start dealing with multiple time zones I would just cut my custom time formatting string down to the shorthand to have the scripting language output in the full ISO 8601 format. But until then, being able to easily sort the the date properly and having the time be more human readable is a more "workable" compromise.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
    • load more comments (27 replies)