you are viewing a single comment's thread
view the rest of the comments
[–] 4 points 3 months ago (7 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.

  • source
  • parent
  • hideshow 7 child comments
  • [–] 7 points 3 months 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

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 3 months 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.

  • source
  • parent
  • [–] 3 points 3 months ago (1 child)
  • [–] 2 points 3 months ago

    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.

  • source
  • parent