Serious question: why is it that so many people apparently have real problems adopting ISO 8601 dates and UTC, in a professional context?
As in, are those somehow fundamentally incompatible with human nature? Or do people just completely lack the cultural awareness to understand that some of their colleagues are used to a different date format than they are, or live in a different timezone, or don't use daylight saving time?
@xahteiwi the USA are still using medieval units and they throw a tantrum if you only slightly suggest that they might want to align them selfs with the 99% of the planet.
It doesn't surprise me they're doing the same with dates 🤷♂️
@xahteiwi because future times are subject to change. Anything in the past happened at a known UTC time, but times in the future are only guesses based on what time zone rules are in place right now.
@xahteiwi
In my workplace? The power dynamics of dealing with a whole industry that has operationalised itself on a specific date format. I just don't use numeric-month date formats at all.
@xahteiwi One blocker for this being consistently adopted at my international workplace is that Google Workspaces ties default Sheets and Docs date standards to the document locale.
You can manually override this per document, but as nobody is going to do that consistently, and US English is the standard language for our business, we have to deal with US-formatted dates everywhere despite the majority of our company being located outside of the US.
@attacus THANK YOU for letting me know how I can get Thunderbird to display ISO 8601 dates!
I will now enjoy the Help→Aboot menu item, and every error message starting with "I'm sorry." Also I will make sure to always hold the door open for my Thunderbird.
Seriously, thanks for that workaround. It'll be immensely useful.
@xahteiwi I’m usually making events for people in many time zones but I don’t always know for sure what zone everyone is in. If I’ve done the work to pick a time that I think works for most/everyone (using said converter) then it’s easy to share it so other people can easily add in their own zone without doing math in case I missed one.
@binford2k Well hang on, I think you're conflating two things here.
(1) Does a meeting chair have the basic decency and respect to check whether all invitees to a meeting can attend at what to them is a reasonably convenient local time.
(2) Does someone use a universal format in written communications, not limited to meeting invites.
@binford2k For example, why would someone use their local timezone for the timeline in a post-mortem report read by people who work in multiple timezones. A post-mortem report that may well contain server log snippets. Whose timestamps are in Etc/UTC.
It boggles the mind, but it's surprisingly common. And I'd like to know why.
@xahteiwi I've always assumed, rather uncharitably that people don't bother to learn ISO8601 (or RFC3339) and UTC due to one or more of ignorance, entitlement, or laziness. Either they don't realise how not doing this could impact others, they don't care, or can't be bothered enough to do anything about it.
I see this in the same way as I see other accessibility and inclusion accommodations.
@mattcen@xahteiwi UTC I don't always fault people for honestly. If you live in a place with daylight savings your offset changes twice a year. And if everyone involved is located in the same TZ – or at least one that changes at the same time – it's easier to not have to remember if it's +1 or +2 this time of year. Another reason to get rid of DST.
@rhoot "If everyone involved is in the same TZ" ... you forgot to add "and always will be". Are you absolutely certain you'll never have a colleague working from Ireland, Greece, or Estonia? As soon as you do, coordinating in UTC is the superior option.
As I explain in the article, the point is not to find the easiest solution for most people, because that always ends up marginalising that ones who are not "most". The point is to create an environment where everyone is on the same footing.
And, coordinating in UTC is definitely the better option as soon as you have a person on the team with a different DST schedule. Examples for a company from western Europe: people from the southern hemisphere, people from north America, people from India.
Add comment