[HN Gopher] ISO 8601: a better date format
___________________________________________________________________
ISO 8601: a better date format
Author : kirbykevinson
Score : 290 points
Date : 2021-02-26 07:08 UTC (15 hours ago)
(HTM) web link (kirby.kevinson.org)
(TXT) w3m dump (kirby.kevinson.org)
| simon04 wrote:
| Has anyone succeeded in configuring GNU/Linux to consistently
| output dates in ISO 8601 format? A partial solution involves...
| ls -l --time-style=full-iso git log --date=iso date
| --iso-8601=s # or date --rfc-3339=s export
| TIME_STYLE='long-iso'
| brnrr wrote:
| Here's an interesting date format most of HN probably haven't
| heard of; military date-time-groups[1].
| 270009LFEB21
|
| Translation: The 27th, 00:09, "L" timezone (+11, NATO
| timezone[2]), February, 2021.
|
| Advantages:
|
| - it's much more compact than ISO8601.
|
| - the most significant information is first; the date.
|
| - the second-most significant information is second; the time.
|
| - the timezone is a single alphanumeric character.
|
| - when military paperwork has a box at the top that says "DTG",
| everyone knows the format.
|
| - I'm pretty sure it's a standard across all NATO militaries.
|
| [1] https://en.wikipedia.org/wiki/Date-
| time_group#Military_Date_...
|
| [2] https://en.wikipedia.org/wiki/List_of_military_time_zones
| scottmcdot wrote:
| I've been caught out by doing date comparisons in Spark SQL using
| string yyyy-mm-dd against string yyyy-mm-dd 00:00:00. It's easy
| to think that the trailing 00:00:00 will have no impact on date
| comparisons but it does! Lesson learnt: use substr(date, 1,10)
| [deleted]
| _raz wrote:
| I like how the first paragraph ends with
|
| "I'm here to (hopefully) change your mind by introducing you to a
| lesser-known date format called ISO 8601."
|
| It seems so foreign to me, and most people i know, to use
| anything but ISO8601 or RFC3339. Might be, as with most things,
| that we here up in the Nordics simply are used to it.
| em500 wrote:
| Free versions of the actual specs:
|
| https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i...
|
| https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0039_i...
|
| Or https://www.iso.org/obp/ui/#iso:std:iso:8601:-1:ed-1:v1:en
|
| The ISO8601 yyyy-mm-dd format is fine and intuitive. What trips
| people up all the time is the ISO8601 yyyy-www-d format (year-
| week-weekday)[1]. People who know it well can appreciate the
| benefits. But it's deeply unintuitive to people who encounter it
| for the first time, that the year in yyyy-www-d sometimes
| differes from the year in the yyyy-mm-dd format. And a perpetual
| source of bugs when inexperienced devs use the wrong year
| specifier (https://news.ycombinator.com/item?id=18762988).
|
| The biggest wart in the spec IMO is the (optional) T in
| 2021-02-26T09:24, which makes the datetime format much harder to
| read for humans.
|
| [1] https://en.wikipedia.org/wiki/ISO_week_date
| AlanYx wrote:
| The "week date" format (yyyy-www-d) in ISO8601 is IMHO why it's
| usually better to refer to RFC3339, which doesn't allow the
| week date format.
|
| So many people are unaware that the ISO8601 format allows "week
| date" and/or don't understand its quirks, and articles like
| this one, which don't even mention that ISO8601 dates can
| appear in this format, compound the problem.
| rswail wrote:
| What about the Durations and Intervals?
|
| The "Week" format is great for planning purposes, because it
| allows a granularity between days and months with another
| whole number per year. Saying that a task will begin 2021-W08
| and then defining the start of the week (ISO8601 says its a
| Monday), tells you exactly when it will start.
|
| Saying the task is 2021-W08/P4D tells you exactly when it
| starts and how long it will take. Or P4D/2021-02-25 says the
| same thing but in terms of when it will end.
|
| They're just as unambigious and just as useful.
| nemetroid wrote:
| Week numbering introduces confusion when interacting with
| countries like the U.S. where weeks aren't considered to
| start on Mondays.
| EdwardDiego wrote:
| Yeah I am a fan of ISO-8601 durations.
| athorax wrote:
| It does mention it though, FTA: ...and a calendar where the
| year is separated not by months but by weeks, which is used
| in finances, but here we're only interested in the basics.
| notatoad wrote:
| i don't think mentioning it in the context of specifically
| excluding it is going to cause any confusion though.
| diggernet wrote:
| Those two LoC links are for the 2016 draft of the 2019
| specification. Hard to say how much it varies. And the ISO link
| only lets you see the definition of terms and symbols. Actual
| syntax details are all locked up.
|
| https://www.loc.gov/standards/datetime/ seems to be a usable
| summary of the 2019 spec, though being just a summary means it
| probably excludes discussion of finer details and
| considerations which might be important at times.
| k_sze wrote:
| I teach my 9-yo daughter to write dates in ISO 8601 format
| whenever permissible, too. I tell her that all other formats that
| her school teaches her are just nonsense and wrong.
| codeful wrote:
| this is responsible and good parenting! thumbs up
| fouronnes3 wrote:
| Is her middle name \";DROP TABLE users;?
| euroderf wrote:
| Raise her on hexadecimal too. She will thrive.
| k_sze wrote:
| Now now, let's not put the cart before the horse. Binary
| first, and then boolean logic, and then automata theory, and
| then...
| [deleted]
| jiggawatts wrote:
| The _real_ advantage is that Azure and AWS and every other US-
| centric cloud service insists on showing me that something
| happened on the 3 /11/2021.
|
| It's a wild guess to figure out if that is the 11th of March or
| the 3rd of November.
|
| Unless there's also another date with a number higher than 12 in
| it, there is no way to tell. None. None whatsoever.
|
| For US staff with US regional settings, it's always obvious which
| date is correct. That is the _one single case_ where there is no
| confusion. This works as expected for just 4% of the world
| population, but it is those 4% of the world that get to decide
| the date format.
|
| It's the most obnoxiously American attitude imaginable to ignore
| this issue because it doesn't affect them... only the _other 96%
| of the planet_.
|
| /rant over
| dfee wrote:
| > It's the most obnoxiously American attitude imaginable to
| ignore this issue because it doesn't affect them... only the
| other 96% of the planet.
|
| I'm not going to comment on the author, though I will
| acknowledge the abrasive, unhealthy attitude.
|
| Anyway, no. I don't think there's a clear "American" standard.
| Maybe there once was, but I'd just see a pile of numbers these
| days. It's hostile to the consumer as it inherently leaves some
| uncertainty of how it should be consumed.
|
| I will say, and maybe this is American - but I don't think it
| is - that I often see dates formatted unambiguously as, e.g.
| March 11, 2021.
| nicoburns wrote:
| It is American. In the UK, we'd write 11th March 2021. But I
| don't mind too much when it's non-ambiguous like this.
| bombcar wrote:
| Is that also how you'd say it? If verbally asked what
| tomorrow is would you say "twenty seven February" or
| "twenty seventh February" or "twenty seventh of February"?
| Americans normally would say "February twenty seventh".
| wankeler wrote:
| Yes. The 27th, or the 27th of February.
|
| To us, US English seems to skip a lot of the small
| joining words of various flavours.
| rswail wrote:
| Well you're actually saying "the 27th day of the month of
| February" and removing some of the small joining words of
| various flavors. :) /s
| bombcar wrote:
| On the Twenty Sixth day of the Month of February in the
| Year of Our Lord Twenty Hundreds and Twenty and One, lo
| did rswail post.
| Gys wrote:
| It is exaclty this attitude what makes the datetime format in
| Golang extremely difficult to use. I always have to double
| check my formatting. I like the basic idea very much, but its
| logic only works for 'local' Americans. The
| reference time used in the layouts is the specific time:
| Mon Jan 2 15:04:05 MST 2006 which is Unix time
| 1136239445. Since MST is GMT-0700, the reference time can be
| thought of as 01/02 03:04:05PM '06 -0700`
|
| Golang was not meant to become a big international language
| from the start? Just a fun internal Google project ;-)
| HenryBemis wrote:
| On presentations for projects I tend to add a couple of 'fun'
| slides. When said projects involve people in the USA, I (almost
| always) include the XKCD ISO 8601 cartoon:
|
| https://xkcd.com/1179/
|
| It is one of my favourites (the "8601", the "Security", and the
| "Bobby Tables")
| samwhiteUK wrote:
| This is mentioned in the article....
| vbezhenar wrote:
| It took many decades to widely adopt UTF-8. I think that one of
| the reasons was that US companies did not really care about
| character encodings, as it's not something they have to often
| deal with. Even today managing multiple keyboard layouts is a
| pain in most operating systems, it's buggy, it does not have
| enough configuration options, it's not convenient. Probably
| because most US developers never tried to use that
| functionality.
| fauigerzigerk wrote:
| But contrary to the date issue, you could at least make a
| case for using ASCII everywhere. I'm not saying it has no
| downsides (e.g information density). It may also be
| unrealistic and culturally insensitive, but there are very
| clear upsides as well. Not so with the U.S date format. It's
| just bad.
| mmis1000 wrote:
| Until people get used to emoji... And not supporting UTF-8 is
| suddenly a big problem even for English people now.
| jacobolus wrote:
| Mac Firefox and Mac Chrome both break a bunch of keyboard
| shortcuts if you use a non-US-ANSI keyboard. Safari handles
| alternate layouts correctly.
|
| Just yesterday I learned that on an ISO Spanish keyboard,
| both of those browsers will pop up a help menu for [?]|7. The
| logic goes: |7 means / on a Spanish ISO keyboard, and |/
| means ? on a US-ANSI keyboard, therefore [?]|7 is by the
| transitive property of inter-layout shift functions
| equivalent to [?]?, which is the shortcut for opening the
| help menu.
|
| They don't pop open the help menu if you press [?]|', the
| _actual_ ISO Spanish layout way to type [?]?
| misterS wrote:
| Stuff like this is the reason why I, as a non-american
| software engineer, use `US_en` layouts on all my machines.
| jacobolus wrote:
| I use a Japanese keyboard that pretends to be a US-ANSI
| on my laptop. The extra keys and narrow spacebar are
| super handy.
|
| Something like http://www.keyboard-layout-
| editor.com/#/gists/9150730dbd4d28...
| Semaphor wrote:
| I use EurKey [0] (I think this was actually recommended
| to me on HN) so I have easy "AltGr" access to German
| characters like ouss. Sadly some tools (most notably
| Microsoft's) have hardcoded shortcuts for some of those,
| which is really annoying.
|
| [0]: https://eurkey.steffen.bruentjen.eu/
| trinix912 wrote:
| I use the Canadian English layout on macOS for most of
| the time, if I need to enter accented letters, I can just
| hold down a normal letter (A) then select an accented one
| from the popup (A). The international English layout
| works the same way if I remember correctly.
| SwiftyBug wrote:
| Same. When I have to use someone else's computer without
| an US_en keyboard I look like an elder learning to type.
| trinix912 wrote:
| The built-in apps seem to handle it pretty well (ex. the
| dictionary app has [?]A / [?]O shortcuts when set to
| Swedish). 3rd party apps often don't care and it gets worse
| the more you move away from plain QWERTY.
|
| Although macOS is good in the aspect that combinations akin
| to AltGr on PCs aren't unique to non-US layouts. I've seen
| programmers assume it's safe to assign shortcuts to Ctrl-
| Alt (which simulates AltGr), making it impossible to enter
| certain characters. Not surprising, as it's not used on the
| US layout (just as there's no extra key next to the left
| Shift).
| happymellon wrote:
| Mac everything breaks for me on a UK Mac when using an ISO
| keyboard rather than their non-standard ISO layout.
|
| Page down only sometimes works, and Command+~ to switch
| same app Windows works in some apps and not others. It's a
| bit of a train wreck when you want to get rid of their
| pointless keys.
| lou1306 wrote:
| Not only Firefox. Cmd-/ is also a _very_ common "toggle
| line comment" shortcut. I think it's the default on Sublime
| and IntelliJ, and any editor that offers a "Sublime
| compatible" preset (like VS code) imitate that. Of course,
| such a shortcut broken out-of-the-box for any keyboard
| layout that lacks a / key.
| jacobolus wrote:
| Yeah, Sublime copied this shortcut (like most of its
| features) from TextMate, and it has since spread widely.
|
| Amusingly, TextMate's author and many early users were
| European programmers with US-ANSI keyboards (because the
| various European layouts are just too painful for writing
| code in ASCII-based programming languages).
| young_unixer wrote:
| And multiple languages. Spell-chackers enabled by default are
| specially annoying.
| SwiftyBug wrote:
| My wife recently bought by mistake a keyboard whose layout I
| couldn't figure out. It took me a full 5 minutes to even get
| to the correct place where I could configure keyboard layouts
| under Windows 10 settings. Then I had to choose the keyboard
| layout I wanted to add. This was a list in a dropdown with
| hundreds of options without an image of what each layout
| looks like so I could not check which option matched the
| keyboard in front of me. There was not even an input field
| where I could test the chosen layout, I had to switch back
| and forth from the Notepad. After many tries, I finally got
| it right: Portuguese. Completely by trial and error.
| majewsky wrote:
| I like the method that Mac OS uses to detect the layout of
| a newly connected keyboard. It brings up a dialog asking
| the user to press specific keys (something like "type the |
| character") until there is only one possible layout that
| would generate the observed keycodes for the characters in
| question.
| eitland wrote:
| Same method as certain mainstream Linux distros has been
| using the last few years? Or has Mac been doing this for
| even longer (I cannot remember how it worked back in
| 2012, the last time I used Mac.)
| bombcar wrote:
| It's really well done - and usually Identifies the most
| common keyboards in only a few key presses.
| exporectomy wrote:
| It doesn't help at all if they try to localize it because then
| it's just 11/3/2021 which is equally confusing and you have no
| idea if they're using your local format or theirs. Any what's
| your local format? The country you're in or the country you
| were in when you signed up for the service or the country your
| VPN server is in? Internet services really need to stop using
| these stupid mistake-inducing, time wasting date formats.
| People might have a sense of unfamiliarity seeing ISO8601
| format but they can still understand it.
|
| I use ISO8601 dates everywhere possible. Paper forms in the
| real world where people look at me strangely, invoices, file
| names which is really handy for sorting, my personal todo
| lists, everything.
| readflaggedcomm wrote:
| It's more obnoxious to be lectured by people who think "June
| 3rd, 2021" isn't shorthand for "AD 2021 June 3rd", which is
| proper logical and sorting order.
| arrow7000 wrote:
| You're saying that 06-03-2021 is shorthand for 2021-06-03 and
| are confused why people don't get that?
| Zekio wrote:
| If it is in the browser it is probably just displaying using
| you local date time format
| [deleted]
| oauea wrote:
| Ha, no.
| jlelse wrote:
| This reminds me about Americentrism:
| https://jlelse.blog/thoughts/2021/02/americentrism
|
| _America first!_
| yread wrote:
| M/D/Y is a bit like the German way of reading numbers. 328
| become three hundred, eight and twenty. Terrible
| slazaro wrote:
| How about french? 99 is four twenties nineteen, 79 is sixty
| nineteen. Languages are fun and fascinating.
| shdon wrote:
| And since the French say ten nine instead of nineteen, it
| becomes four twenties ten nine.
| rswail wrote:
| But nineteen is just "nine and ten" with the "and"
| removed.
|
| English has a word for twenty and its used in the French
| way "Four score and seven years" is "quatre-vingts et
| sept".
| mywittyname wrote:
| This explains, to me, at least, the whole "four score and
| seven years ago" speech. I always wondered the reason
| behind such a silly way of presenting a number, I just
| figured it was archaic.
|
| Nope, just French.
| smcl wrote:
| I think your response to these language quirks can vary
| depending on your familiarity with the language:
|
| - to an outsider, learning that a concept exists: "that is
| an interesting thing"
|
| - to a beginner, trying to construct the right form or to
| detect it in quickly spoken speech: "this is annoying and I
| hate it"
|
| - to an intermediate speaker and beyond: "eh it's maybe
| weird but whatever"
|
| I used to hate noun declension in Czech as a beginner (7
| cases x plural/singular = 14 forms a noun can take[0])
| because it's intimidating and unintuitive for an English
| speaker, but now I'm at the "meh" stage.
|
| [0] - then consider that there are 3 genders, and each
| gender has a handful of "models" (patterns for declining
| words that look a certain way), and also a bunch of
| exceptions. Not the hardest thing in the world, for sure.
| But it's definitely a bit of a pain
| bombcar wrote:
| I've always thought it's interesting how the languages
| like that (most of the Romance languages have declensions
| and such) add error detection and even correction - you
| can figure out parts that are missing or got changed by
| the lack of agreement between the various forms.
|
| You may not be able to correct it from the Information
| available but you'll know something went wrong.
| dvh wrote:
| Still better then russians: ten, twenty, thirty, bag of
| furs, fifty, sixty, ...
| trinix912 wrote:
| Same deal in Slovenian. Twenty one is written as
| "enaindvajset" ("ena" - one, "in" - and, "dvajset" - twenty)
| which is the same format as used in German ("einundzwanzig").
| ncmncm wrote:
| Let's not even talk about Danish numbers.
| heipei wrote:
| I don't know, I'm German and deal with US folks a lot, for me
| it's like this: Date written with slashes or dashes (3/11/2021
| or 3-11-2021) implies US-based month/day/year. Date written
| with dashes and the year first and zero-padding (2021-03-11)
| implies year-month-day, aka ISO8601. Date written with dots and
| without padding (11.3.2021) implies my native format,
| day.month.year.
| rodelrod wrote:
| but then you get an email from an American living in Paris
| and it's 11/3/2021 with dashes and God knows what he meant.
| edoceo wrote:
| Isn't the point of ISO to eliminate that guess/search process
| and replace with 100% accuracy on read?
| GordonS wrote:
| You can change the display format, but I really wish M/D/Y
| wasn't the default - it's just too ambiguous.
| TeMPOraL wrote:
| Yup. I hate // AM/PM formats with a passion. Doesn't help that
| I work with UK teams now, and _their_ "natural" date format is
| 3/11/2021, with meaning of 3 and 11 reversed to what they'd
| mean for Americans...
|
| _sigh_.
|
| ISO 8601 everything. I'm religious about it. I write it in
| messages, on government forms, anything that doesn't _force_ me
| to use a different format. On a bit of my insistence, we use
| ISO 8601 notation for all dates at home. I think the benefit is
| quite obvious once one starts using it.
| andy_ppp wrote:
| Format the date on the frontend using
| date.toLocaleDateString() and let the browsers locale do the
| work for you (assuming you're in JS and on the web).
| jiggawatts wrote:
| Short of stepping through the JavaScript line-by-line, how
| do you tell the difference between these two dates?
| 3/11/2021 3/11/2021
|
| The difference is one was formatted incorrectly, and the
| other was formatted correctly. One is 2021-03-11, the other
| is 2021-11-03.
|
| Even having been told that there's a difference, you
| _cannot_ know which is which.
|
| Even if you _think_ you know because you found an
| unambigious date like 31 /11/2021 somewhere, you _still_
| shouldn 't be confident because there are many sources of
| dates, and they're formatted by many different pieces of
| code. Some may be doing the "right" thing, some may be
| using US formatting. A complex web application like the
| Azure or AWS consoles might have literally thousands of
| sources of dates formatted by a thousand different pieces
| of code.
|
| Before the 12th of the month, they're all totally and
| utterly useless for 96% of the world unless they use ISO
| 8601.
|
| BTW: I just tested this with the Azure portal by clicking
| through some Log Analytics related things. I got it to show
| me 3 different date formats, 2 of which would have been
| ambiguous earlier in the month, and one of which _changed_
| between two tenants. So even if you learn which parts of
| the UI you can trust to be correct, switching tenants will
| invalidate your experience.
| andy_ppp wrote:
| You're making the assumption that users know YYYY-MM-DD
| is the date format and not YYYY-DD-MM. I bet if you asked
| non-developers the answers you would get would be pretty
| random, probably more errors than the locale on their
| machine.
| beowulfey wrote:
| the point is, no program writes the date YYYY-DD-MM (or
| at least, it's very rare).
|
| users who don't know what ISO 8601 is would learn, simply
| because when that format is used in software, it is
| _consistent_!
| skissane wrote:
| > YYYY-DD-MM (or at least, it's very rare)
|
| Wikipedia claims [0] that is the date format in
| Kazakhstan, but only for the Kazakh language, not for
| Russian. (Maybe there is someone here from Kazakhstan who
| can confirm if that is true or not.)
|
| A lot of companies don't have any employees in Kazakhstan
| (which means they can ignore this for internal systems);
| and many companies wouldn't have any customers there
| either (which means they can ignore it for external
| systems as well).
|
| [0] https://en.wikipedia.org/wiki/Date_format_by_country
| rhn_mk1 wrote:
| > Date().toLocaleDateString() > Uncaught TypeError:
| Date().toLocaleDateString is not a function
|
| That doesn't seem like a standard API call.
| teh_klev wrote:
| Looks like an instance method, rather than a static.
| bmn__ wrote:
| It is standardised and widely implemented.
|
| https://developer.mozilla.org/docs/Web/JavaScript/Referen
| ce/...
|
| Your code has a bug, missing constructor.
| TeMPOraL wrote:
| No. The computer cannot magically detect the preferences of
| an actual user. This is a kind of "90% solution" that
| excludes people whose locale setting doesn't match their
| preferences, which is arguably quite common. Reasons
| include buying your OS/computer from abroad, or one that
| was imported and resold, getting a work machine set up for
| a different country, not knowing how to fix locale up
| yourself, traveling (localizing websites based on user's
| location is idiotic, but it keeps happening)....
|
| What developers also suck at, in practice, is data-typing
| their output properly. If I see 5/2/11 on a US site while
| using my work laptop, I can't be sure whether it's the US
| notation written by the author, or date localized by my
| browser for UK format, which has the day and month
| reversed. I can't tell if the date is localized or not, or
| how it was generated.
|
| Just say no to all that complexity, and use ISO 8601
| everywhere. My controversial view here is: in this
| industry, we're still in a privileged position to _force_
| the entire world to standardize on the important things,
| like dates and times. So let 's do so, and get everyone on
| board with an international standard, instead of just
| unwittingly pushing the USA defaults. We _are_ pushing
| things, that comes with "software eating the world". So
| let's push things that make sense.
| andy_ppp wrote:
| Okay, well I'm pretty sure for most apps I've worked on
| this has been fine according to business requirements and
| solved the problem of our users. Do you have statistics
| on which users have their locale's set wrongly and can
| you explain why the browser provides this functionality?
| Maybe you should campaign for it to be removed on their
| mailing lists?
|
| Also, should you want to change the locale (via a
| preference or override somehow), in most browsers you can
| pass it as the first parameter.
|
| I think your view is very much a classic developers view
| - sure it would be nice to be able to dictate software
| requirements to businesses but you are probably going to
| be quite angry as your version of right and someone
| else's are going to be different.
| alexvoda wrote:
| That's why we have international standards. So that 1
| version of right and all others are wrong. And no matter
| how arrogant it might seem, at least for computing use
| cases, ISO 8601 is right and other date formats are
| wrong.
|
| There are absolutely no usecases where the US date format
| makes sense. No, having it written in the order you
| prefer to pronounce it is not an argument. Especially not
| in the language where you have to learn spelling. It is
| just what US people are used to.
| andy_ppp wrote:
| I don't disagree, in an ideal world great, let's get
| everyone to change to ISO8601. I'm a big fan. However
| until developers become in charge of all the decisions
| (imagine!) I've suggested a reasonable solution that most
| people can use to format dates in 99% of users locales
| with too much hassle. There are more interesting bridges
| to die on.
| TeMPOraL wrote:
| > _However until developers become in charge of all the
| decisions (imagine!)_
|
| The thing is, we sort of are! As I mentioned upthread,
| notation and language are being strongly influenced by
| increased use of software in every facet of our lives.
| The way people note numbers, dates, express search terms,
| etc. are all impacted by what the software accepts and
| displays by default. We have an opportunity here to push
| for positive cultural change around international
| standardization, so let's make good use of it, instead of
| squandering it by just implementing whatever seems to
| resemble the local status quo the most.
| cesarb wrote:
| > ISO 8601 everything. [...] on government forms
|
| On government forms (and other paper forms), I use 3/11/2021.
| It's unambiguous; nobody would expect it to mean anything
| other than "3rd of November of 2021". The ambiguity only
| happens once you add the Internet to the mix, and even then,
| only in English-language websites (I wouldn't expect anything
| other than DD/MM/YYYY on Portuguese-language websites, and
| the same probably applies to most other languages).
| TeMPOraL wrote:
| You don't need the Internet for ambiguity to occur, you
| only need to go international. It may be because you
| travel, or work with foreigners, or handle mail/packages
| to/from abroad. Or use any kind of software, because unless
| you live in the US, almost all software you use is made by
| foreigners in a foreign country.
|
| In a globalized economy, local date formats are just one of
| those annoyances that serve no benefit, cause everyone
| unnecessary hassle, occasionally causes expensive errors,
| and that should have long ago been replaced with an
| international standard.
| timvisee wrote:
| Yes! I constantly get complaints when using ISO 8601 on
| school documents. But I won't stop using it.
| MaxBarraclough wrote:
| I guess the complaints are because the format is unfamiliar
| and strikes non-software people as being non-standard.
|
| Perhaps use a format like _3 /Nov/2021_?
| joshspankit wrote:
| No.
|
| People were _unfamiliar_ with showering and brushing
| their teeth. We move forward.
| TeMPOraL wrote:
| That's missing the point of pressuring the other side to
| adopt ISO 8601.
|
| (And in general case, of electronic documents with wider
| audience, using 3/Nov/2021 excludes people who don't know
| English (or the language in which you encoded the name of
| the month).)
| anoncake wrote:
| The vast majority of documents are written in a language
| anyway so you can safely encode the date in it. Does any
| other language even have two different, conflicting date
| formats like that?
| TeMPOraL wrote:
| English is the only one with conflicting date formats I
| can think of (US vs UK), but in case of government and
| corporate documents, those are sometimes bilingual - with
| form labels in the primary language having a small-font
| translation to English below.
|
| (Real use case: I recently sent a Polish equivalent of
| OSHA form to my line manager in UK, and I used a
| bilingual version. As you can imagine, I set the example
| by filling my part of the document using ISO 8601 for
| dates, so that once the document returns to the Polish
| corporate office, there won't be any possible
| confusions.)
| exporectomy wrote:
| Can still be ambiguous because "list." means October in
| Croatian but November in Czech. Also, "lip." is July in
| Polish but June in Croatian and "srp." Is July in
| Croatian but August in Slovak.
|
| Maybe it's just Croatian that's ruining it for everyone.
| TeMPOraL wrote:
| I'm guessing every language ruins _something_ for
| everyone else.
|
| Around this part of the world, almost everyone calls tea
| by some variation of the word "chai". But not us. In
| Polish, it's _herbata_!
| knorker wrote:
| Sure you can tell. You just hire an investigator to find out
| who wrote the memo, and find where in the world they grew up,
| in what culture.
|
| If the answer comes back very US, then it's middle endian US
| format. Else it's DMY.
|
| Note that the article is wrong to just say "dd.mm.yy" is used
| in "Europe". Some countries use yyyy-mm-dd and others dd/mm/yy.
|
| The US format is the only one that's retarded, though.
| PowerBar wrote:
| Canada is even worse, we can't decide which one to use so you
| _never_ know what format it 's in.
|
| I was once sent paperwork to fill out that had dates
| requested in both MM/DD/YYYY and DD/MM/YYYY formats on
| different pages.
| notatoad wrote:
| the upside of Canada's incredibly stupid date formats is
| that nobody complains when you try to use ISO8601 format
| instead, we're all somewhat used to date formatting being
| flexible.
|
| My american users get _very angry_ when they see a date
| that isn 't in dd/mm/yy format.
| lostlogin wrote:
| > The US format is the only one that's retarded, though.
|
| I wonder how it started? A skim of the internets hasn't
| enlightened me.
| bombcar wrote:
| It's a representation of how us Americans talk - we rarely
| say 26th of February and instead say February 26 - and if
| necessary tack on the year. It feels exceptionally awkward
| to say 26 February, thought saying "twenty twenty one
| February 26" sounds very strange, too.
|
| But people are very good at verbally saying different than
| is written.
| frn123 wrote:
| No native speaker but isn't 4th of July more common than
| July 4th?
| TT3351 wrote:
| You could even say "The Fourth" and almost all Americans
| would understand. I think that's why; [begin speculation]
| it's such an exceptional date it necessitates saying it
| differently.
| knorker wrote:
| So write YYYY-MM-DD!
|
| But also, the most sacret of all days has been honored by
| the one day of the year "said properly" fourth of july!
| lostlogin wrote:
| Changing formats is just asking for a large event on 9
| November.
| jacobolus wrote:
| I have taken to writing 11 March 2021 or similar whenever
| possible. But sure, 2021-03-11 is also fine, when trying to
| save something machine readable.
|
| The US conventions are indeed horrendous.
| Mordisquitos wrote:
| Another great thing about 2021-03-11 is that, even putting
| aside its technical advantages, it is (probably) intuitively
| understandable to any literate person even if they have never
| seen it before and, most importantly, it is almost immune
| from confusion because (hopefully) nobody is insane enough to
| expect YYYY-DD-MM. YYYY-MM-DD both satisfies the American
| intuitive expectation of month coming before day, and the
| Worldwide expectation of time units being displayed in a
| logical order.
| jacobolus wrote:
| I have seen non-Americans write YYYY/DD/MM before. Hyphens
| are key here.
| happymellon wrote:
| That is horrifying.
|
| I am glad I have never met these people.
| PeterisP wrote:
| yyyy.dd.mm. (but not with hyphens!) are commonly used for
| all the languages where their grammar and word order
| means that the spoken way to say dates is like
| "twothousandtwentieth year's first march".
| happymellon wrote:
| eye_twitch.gif
| eythian wrote:
| Non-scientifically, about 20% of people won't:
| https://twitter.com/troyhunt/status/978747364105011202
| silvestrov wrote:
| Another great thing about 2021-03-11 is that it ascii sorts
| correctly.
| fogihujy wrote:
| This is the big one when it comes to sorting files and
| directories on disk. It makes sorting and finding what
| you look for so much easier.
| lurquer wrote:
| > it is almost immune from confusion because (hopefully)
| nobody is insane enough to expect YYYY-DD-MM. YYYY-MM-DD
| both satisfies the American intuitive expectation of month
| coming before day,
|
| I disagree. (Or, perhaps I'm insane...) I paused when
| coming across the ANSI version in the article as I couldn't
| tell whether it was YYYY-MM-DD or YYYY-DD-MM. I thought
| there was a typo or something.
|
| I've nothing against the standard, but as Americans have no
| 'intuitive' reason to sort the fields by significance, it
| is natural for some to incorrectly assume the ANSI version
| is just the American version written backwards.
| otherme123 wrote:
| I also always write 11 maarc 2021 or similar whenever
| possible. No problems so far.
| eqvinox wrote:
| I go with [2021Nian 03Yue 11Ri ] . Free bonus test included
| for whether software handles alternate numerals ;)
| 3np wrote:
| Tangent, but I do like the space-efficiency in some cases
| for Chinese/Japanese characters that make them great for
| status bars and terminal prompts.
|
| E.g. a single character to unambiguously denote weekday,
| window layout (Quan /Guang /Gao ), and others. Renders
| everywhere as long as you have a decent CJK font. Bonus:
| looks a lot less stupid than emojis.
|
| My desktop terminal prompt right now shows [Jin
| 19:58:22] - just a single character and as long as it's <
| 7d ago it's unambiguous what time and day a command
| exited in case I forget.
| eqvinox wrote:
| Absolutely agree. Also in some cases you get "tables"
| aligned for free (... if there's nothing else length-
| varying.)
| bhaak wrote:
| > My desktop terminal prompt right now shows [Jin
| 19:58:22] - just a single character and as long as it's <
| 7d ago it's unambiguous what time and day a command
| exited in case I forget.
|
| You're a bit cheating there :) It's one character that
| takes up 2 columns.
|
| You could get away with using the first 2 characters from
| the English names as they are unique. But I know that in
| English that's unusual but for example in German, the 2
| letter abbreviation are the standard ones.
|
| You say weekday, but Google translate and Wikipedia say
| that Jin means gold?
| 3np wrote:
| Maybe a bit cheating - but it's nice with the
| consistency, and visually it becomes a lot more clear and
| immediate at least for me.
|
| "Jin " would be short for "Jin Yao Ri ", a common way to
| abbreviate weekday names in calendars etc and yes, Friday
| is indeed the day of gold - I like to imagine it's the
| old pay day for workers maybe? :D
| sirn wrote:
| Jin from Jin Yao Ri (Kinyobi) means Friday. The letter
| correspond to the planet the weekday was named after,
| just like in English (Jin Xing is Venus)
| majewsky wrote:
| The planet-weekday combination is harder to see in
| English than e.g. in Romance languages like French
| because English derived its planet names from Roman gods,
| but its weekday names from Norse gods (e.g. Friday comes
| from Freya). German is similar, having Freitag for Friday
| (again from Freya) and Donnerstag for Thursday (from
| Thor).
| saithound wrote:
| Slightly off, but this is fun, so let me expand (along
| with a minor correction):
|
| The days of the week were named after the seven classical
| planets of astrology (by the Romans, who in turn named
| the seven classical planets, and hence the days, after
| Roman deities).
|
| The names were taken up by speakers of Germanic
| languages, and eventually underwent semantic loan
| translation: Germanic deities were substituted for the
| Roman ones (with the exception of Saturday). Some people
| say that the Germanic deities themselves were culturally
| identified as one and the same as the Roman deities, but
| we probably won't ever know for sure (interpretatio
| germanica, analogously to the interpretatio graeca, the
| identification of Egyptian, Roman and Greek deities [1]).
|
| And now, a minor correction: The day of Venus, Friday
| bears the name of the Germanic goddess Frigg, who is not
| the same as the Norse goddess Freyja. The meeting of the
| two characters, in a debate against Loki, is described in
| the Poetic Edda [2].
|
| [1] https://en.wikipedia.org/wiki/Interpretatio_germanica
| [2] https://en.wikipedia.org/wiki/Lokasenna
| dingaling wrote:
| > only the other 96% of the planet
|
| Ahem, ISO8601 fails for Taiwan and Japan...
| lloeki wrote:
| The best part is when someone tried to make it work for the
| other 96% of the world but failed for 2% of the dates (probably
| because the other locales got less testing, again very US
| centric), so one ends up with mixed US/EU dates (the latter
| often also uses / as a separator, as . is only used in some EU
| countries).
|
| It's so much fun trying to retrospectively correlate fatal
| incident data and failing to make sense of anything because
| some dates are inconsistent. Of course those dates are all the
| ambiguous kind, otherwise it wouldn't be -that- hilarious /s.
| inetknght wrote:
| > _It 's the most obnoxiously American attitude imaginable to
| ignore this issue because it doesn't affect them..._
|
| As an American I can fully confirm that 3/11/2011 is
| obnoxiously ambiguous. It affects us. But most Americans
| (particularly outside of science / engineering fields) are too
| thick-headed to recognize the problem or think about ways to
| improve it.
|
| So I do what I can. I don't even ask what time format something
| belongs in. I just write ISO8601 by default. If someone
| complains then I point them to the international standard and
| ask whether we want to be an internationally standards-
| compliant company.
|
| One manager said that our customers aren't international. It
| was a reasoned argument and I like having customers. But all
| others drop the argument at "international company" and
| "standards-compliant"
| fatnoah wrote:
| >So I do what I can. I don't even ask what time format
| something belongs in. I just write ISO8601 by default. If
| someone complains then I point them to the international
| standard and ask whether we want to be an internationally
| standards-compliant company.
|
| This is my approach as well. I've never gotten a complaint
| about it, which proves to me that the format is
| understandable AND unambiguous.
| Mauricebranagh wrote:
| Point them at the fiasco where NASA mixed up Imperia and
| Metric.
|
| And also ask but why are we not targeting international
| customers.
| inetknght wrote:
| I have indeed done the former when discussing why I use
| meters instead of feet.
|
| The latter was an ice rink whose customers are very
| physically local. Local teams do compete internationally
| but the ice rink itself isn't an international org.
| amelius wrote:
| How can you take an international standard seriously when it
| is based on the number of years since some prophet of some
| specific religion was thought to be born?
| oxfeed65261 wrote:
| Can you suggest a better alternative which you would take
| seriously? A Kelvin-like year based on the approximate date
| of the Big Bang (as CE/BCE is based on an approximate
| year)? Logical but unwieldy.
| notatoad wrote:
| The AWS console is absolutely terrible for this, not just
| because it disobeys my preferred date format but because it's
| not even internally consistent. sometimes it converts
| timestamps to my local timezone, sometimes it displays them in
| UTC, sometimes it displays them in ISO8601 format, sometimes it
| displays them in US format.
| FeepingCreature wrote:
| Another example of obnoxious American attitude: the TZ variable
| in POSIX.
|
| TZ=UTC+8. Is your system now set to the timezone UTC+8? No,
| it's set to UTC-8. Why? I don't know, but I suspect the people
| who developed this convention, who lived in the US, just didn't
| want to type a minus.
| jacobolus wrote:
| The TZ format counts how many hours behind UTC you are (how
| many hours should you add to get UTC time). The ISO format
| counts how many hours ahead of UTC you are. Neither choice is
| inherently correct, but the discrepancy is pretty annoying.
|
| Use https://en.wikipedia.org/wiki/Tz_database names instead.
| davidbanham wrote:
| A note from the front line. I actually use 8601 dates in a date-
| heavy consumer product ( https://clubman.app ) and it's hands
| down the feature I most consistently get user feedback on.
|
| It's always "Why are the dates all American format? Can you
| change them to English?" And then I try to patiently explain that
| they're actually international format.
|
| People seem to have internalised that any date format they find
| slightly unfamiliar is "the bad American one"
|
| I'm in the process of cutting everything I can over to "24th Jan
| 2020" style.
| jamie_ca wrote:
| Another advantage to outputting 8601 dates is it's easy to
| mechanically parse - you can probably find some JS to rewrite
| the 8601 dates coming from the server into whatever the user's
| current locale is. Bonus points: if your timestamps are UTC,
| the frontend reformatting can even take timezones into account
| (such that an American and an Australian could correctly see
| different dates for the same timestamp).
| davidbanham wrote:
| I did try rewriting dates into a user's locale as specified
| by the browser. The trouble there is that a lot of people
| seem to have that set to en-US rather than en-AU. So I still
| got a bunch of people unhappy that the dates were American!
| rchaves wrote:
| yyyy-mm-dd is so nice you can just work with strings for your
| date stuff, converting to objects and back is tedious
|
| Shameless plug: I built a python library to do exactly that
| https://pypi.org/project/yyyy-mm-dd/
| grenoire wrote:
| Quite nifty and clean; I think this could play well with
| support for the duration (P-Y-M-D...) format in ISO 8601 that
| declares a positive offset.
| https://en.wikipedia.org/wiki/ISO_8601#Durations
| akavel wrote:
| Interesting, didn't know about that! Do you know of some
| canonical way of expressing negative offsets in spirit of ISO
| 8601? I don't seem to see those mentioned in the article...
| rswail wrote:
| You can specify an interval as start/duration, start/end,
| or duration/end.
|
| So you could specify a negative offset as a duration and
| the end time.
|
| P2H/2021-02-26T13:30Z is two hours prior or T11:30Z on the
| same date.
| grenoire wrote:
| Unfortunately not, for the project I'm working on right now
| I only needed 'forward' durations. There's a W3C extension
| that proposes a preceding - sign for negative durations,
| which I think it's fair
| https://www.w3.org/TR/xmlschema-2/#duration. The ISO
| standard explicitly declares durations to be non-negative,
| on the other hand.
|
| As close to canonical as you can get.
| globular-toast wrote:
| It's not tedious if you do it right. All of your conversions
| should be done in your I/O layer and nowhere else. For many
| applications that means there's a single place to do it. Hardly
| tedious.
|
| I notice that your library is targeted at notebooks, though. It
| seems useful in that context, but not for general programming.
| antihero wrote:
| It is a good format for sorting, but misses the point of use. As
| humans, we want to read the most significant data to our use case
| first.
|
| The author confuses _value to the reader_ with _magnitute_. In
| normal numbers, they happen to be the same thing.
|
| In most cases, we want to discern between days first, them
| months, then years. If you look at a list of dates:
|
| 2021-01-01
|
| 2021-01-02
|
| 2021-01-03
|
| 2021-01-04
|
| You're just going to be seeing a heap of noise before you see the
| actual number you care about.
|
| If you consider that days are the most _valuable_ , then months,
| then years, you get the UK/European format.
|
| 01/01/2021
|
| 02/01/2021
|
| 03/01/2021
|
| 04/01/2021
| TeMPOraL wrote:
| > _In most cases, we want to discern between days first, them
| months, then years._
|
| That really, really depends on particulars on your life. While
| I strongly dislike the US format of putting the month first,
| the irony is, the month _is_ the most important datum for most
| of the dates I read with. Year is usually obvious given
| particular context (it 's typically either the current one, the
| next one, or sometimes the previous one). Days don't matter for
| anything that isn't in the same month. I'd go as far as saying
| that months are typically the most important for most people in
| XXI century, then days, then years.
|
| But that's no problem for punctuated date formats in general.
| People don't read things linearly at letter level, they
| deconstruct tokens in a random-access way. Separators like - or
| / help clearly identify which part is which (compare how easy
| it is to read 03/01/2021 with 03012021), and there's no extra
| cost associated with reading off the part in the middle.
|
| The benefits of YYYY-MM-DD notation _on top of_ the above are:
|
| - With all terms being fully expanded, dates line up vertically
| as well, which helps when dealing with stacks of documents or
| tabular data.
|
| - Being ordered by magnitude like normal numbers provides a
| Schelling point for interpretation[0]. That is, when a random
| person who wasn't exposed to much computing or
| internationalization before sees 2021-01-03, they will
| automatically assume that 01 must be the month, because writing
| YYYY-DD-MM would be dumb and inconsistent with how numbers are
| written in general.
|
| Yes, both of these apply to DD/MM/YYYY, _but_ , YYYY-MM-DD also
| gets you sane lexicographic sorting, which the UK/European
| format doesn't. It's super useful feature not just when dealing
| with computers, but also when perusing any kind of date index.
| ISO 8601 dates work much like words in a dictionary, you can
| binary-search through them.
|
| --
|
| [0] - https://en.wikipedia.org/wiki/Focal_point_(game_theory)
| inetknght wrote:
| > _In most cases, we want to discern between days first, them
| months, then years. If you look at a list of dates:_
|
| > _2021-01-01_
|
| > _2021-01-02_
|
| > _2021-01-03_
|
| > _2021-01-04_
|
| With you so far.
|
| > _You 're just going to be seeing a heap of noise before you
| see the actual number you care about._
|
| 100% disagree. There's less noise here than having days from
| other months or years mixed in. If there's noise here then
| either I am on the wrong page and need to navigate to the
| correct year or else the data I want has few data points.
|
| > _If you consider that days are the most valuable, then
| months, then years, you get the UK /European format._
|
| > _01 /01/2021_
|
| > _02 /01/2021_
|
| > _03 /01/2021_
|
| > _04 /01/2021_
|
| Maybe. Your list is contrived. Here's another.
|
| 01/01/2021
|
| 01/03/2021
|
| 01/04/2020
|
| 01/10/2021
|
| 01/11/2019
|
| 02/01/2021
|
| 02/13/2019
|
| 02/20/2021
|
| Those numbered days are completely irrelevant to each other in
| most circumstances. Now other months and even other years are
| mixed in. Expand this list to 1000 data points and good luck
| figuring out where your data's at.
| lovelyviking wrote:
| I invented for myself this one: 2021-02-26_08-30-00_
|
| And never looked back. Because since then I have no problems with
| dates anymore.
|
| If there is a need for 'ms' you can add them in the end or add
| more sections for more precision.
|
| For me it solves it.
| lazyasciiart wrote:
| One day you'll need to read a date written by someone else.
| lovelyviking wrote:
| Or perhaps one day you'll need to read this one :)
|
| If I meet another date format I convert it to this one when
| possible.
|
| For instance I setup this date format for MacOS in
| Settings->Language & Region->Advanced->Dates: this way:
|
| Short: y-MM-dd
|
| Medium: y-MM-dd
|
| Long: y-MM-dd_HH-mm-ss
|
| Full: EEEE,y-MM-dd_HH-mm-ss
|
| You just put those strings there and it should work.
|
| In terminal you can do it too:
|
| date "+%Y-%m-%d_%H-%M-%S_"
|
| or
|
| datetime=$(date "+%Y-%m-%d_%H-%M-%S_")
| mdip wrote:
| Date/Time is frequent topic[0] for me.
|
| Generally speaking, a lot of these issues are knowing when it's
| appropriate to use what format. When displaying a date to a user,
| you do it in their configured local time, and in their configured
| date/time format. I don't think the author is advocating changing
| that behavior[1].
|
| Where the problem comes in is "how you store date/time values".
| Normally, I don't find myself arguing as to the format. Generally
| speaking, people default to ISO-8601 for log file naming (many
| probably not realizing that's what they're doing -- aiming only
| for a naturally sortable list). The places I tend to store dates
| (databases) define _how_ they 're stored, otherwise. That doesn't
| mean a developer isn't going to store the date in server
| local/user local time (and often make discovering the reference
| time zone impossible). Please don't do this. Store in UTC.
|
| I'm not sure why the author is so hung up about the ordering of
| the dates, but while I worked in telecom, I briefly had a boss
| that was really particular about that (I've worked for a few
| folks in the UK, only this first boss had hang-ups). The US
| ordering probably originates from the most common way dates are
| spoken in the US: "Januaray 17th". A year is less frequently
| necessary, but when it is, it's tacked on the end. I don't think
| anyone thinks the way we write dates is particular superior, it's
| just the way we've done it since we first learned about dates.
|
| One thing I learned when I started working regularly with non-US
| folks. Never use numerical dates. Even if you write it in the
| format they are comfortable with, if there's any ambiguity,
| they're likely to assume you wrote it in the US format. I started
| writing/abbreviating month names. I ended up altering the written
| order, as well "17th of January or 17 Jan" because that
| particular first boss jokingly-non-joked about how obnoxious the
| other way was.
|
| Everybody's got their tabs/spaces war, I guess!
|
| [0] OK, so it's more of a pet peeve.
|
| [1] While it would be nice if we all used the same date/time
| format in our day-to-day life, it's one of those things that I'll
| wager will never happen... and I'd argue that doing so would
| cause more problems than it would help.
| aimor wrote:
| My biggest complaint is that Windows doesn't allow ":" in file
| names. I just substitute "-", which is good enough, but not
| standard.
| valenterry wrote:
| ISO 8601 contains durations and time intervals which are totally
| undervalued!
| (https://en.wikipedia.org/wiki/ISO_8601#Time_intervals)
|
| E.g.: 2021-05-01T12:00:00Z/P2H
|
| They are so convenient. Ever stored a tuple of two datetimes to
| model a time interval? E.g. a meeting that takes place on
| 2021-05-01T12:00:00Z and takes two hours?
|
| Don't! Instead, store it as an interval:
| "2021-05-01T12:00:00Z/P2H"
|
| Or are you creating an API where a duration or a time interval is
| expected? E.g. "give me all sales in this time period..."
|
| Using time intervals for that makes it so much more easy for
| people to code against it and execute manual queries.
|
| For JVM developers, there is a library out there that has amazing
| support: https://github.com/MenoData/Time4J
|
| For python developers, there is pendulum which supports most of
| the functionality.
| em500 wrote:
| I agree it's undervalued. Sadly too few people are aware that a
| standard notation for time intervals even exists, and external
| software support is very sparse (e.g. lacking in Pandas, R,
| most SQL implementations). Which leads to too many devs rolling
| their own buggy solutions for datetime arithmetic.
| twic wrote:
| As of Java 8, the JDK also has support for ISO duration
| formats, via java.time.Period and java.time.Duration.
| valbaca wrote:
| 100% agree that it's undervalued.
|
| Was just in a software design meeting where they were trying to
| figure out how to represent exactly this: a time interval.
|
| I had to repeat "Just read ISO 8601 and use it" like a dozen
| times.
|
| "Bu-bu-but what if we want to represent a recurring..."
|
| READ IT. AND USE IT.
| hannob wrote:
| There's another aspect you may not know about: It's close to how
| it's done in chinese, which is 2021Nian 3Yue 17Ri . They use
| different separators (the chinese words for year, month and day),
| but it's close enough.
|
| Given that china is the country with the largest population it
| may not be a bad idea to use something a large number of people
| will easily understand.
| contravariant wrote:
| It's also neat how the character for month and day are the same
| as characters for moon and sun respectively.
|
| I suppose that means we could also do the following if we
| really wanted a western version:
|
| 2021[?]317
|
| Edit: Turns out that hackernews isn't quite astrological
| unicode compliant yet but imagine the astrological symbols for
| sun and moon in there as well.
| JdeBP wrote:
| Markus Kuhn has been making this point since 1995.
|
| * https://www.cl.cam.ac.uk/~mgk25/iso-time.html
| CyberRabbi wrote:
| Maybe we should also start speaking Chinese since it may not be
| a bad idea to use something a large number of people will
| easily understand.
|
| Edit: this is not sarcasm. It's simple logic, unless there is
| something wrong with learning other languages.
| jpetso wrote:
| Being able to speak popular languages is in fact often
| advantageous for the multi-linguist.
| CyberRabbi wrote:
| Very good and very true point. Multi-linguism only has
| upsides.
| FooBarWidget wrote:
| Lots of people learn English because a large number of people
| speak it. Why should it not apply to Chinese or other often-
| used languages?
| CyberRabbi wrote:
| Thats exactly the point I'm making in my post. Glad you
| agree
| FooBarWidget wrote:
| All right. Seeing your downvotes, I thought you were
| being sarcastic.
| TeMPOraL wrote:
| I think we should. At the very least, our children should.
|
| That's why I'm planning on having my daughter learn Mandarin
| along with English - to prepare her for the shape of the
| economy she'll be living in.
| CyberRabbi wrote:
| I'm doing the same with my kids. Cheers.
| monsieurbanana wrote:
| Sigh... I never remember the names of the logical fallacies,
| I have to look up them, thanks a lot.
|
| Anyways, here's yours: Slippery Slope.
| CyberRabbi wrote:
| Where's the logical fallacy? More people natively speak
| Chinese than any other language in the world. If you want
| to maximize the exposure of your ideas, it's only logical
| to render them in Chinese. It's the same reason I prefer to
| distribute applications over the web.
|
| FYI: English has ~1100 million total speakers but only 318
| millon native speakers, while Chinese has 918 million
| native speakers. https://www.visualcapitalist.com/100-most-
| spoken-languages/
| richrichardsson wrote:
| > More people natively speak Chinese than any other
| language in the world
|
| You've made the assumption that all Chinese people speak
| one language, which is a false assumption I'm afraid [1].
|
| [1] https://en.wikipedia.org/wiki/Languages_of_China
| [deleted]
| bonzini wrote:
| All of them can read the characters for year/month/day
| though.
| CyberRabbi wrote:
| > You've made the assumption that all Chinese people
| speak one language,
|
| No I didn't. I cited the fact that Chinese is the largest
| natively spoken language in the world, by an order of
| magnitude.
| dataflow wrote:
| https://www.statista.com/statistics/266808/the-most-
| spoken-l...
|
| Unless it's already out of date...
| ginko wrote:
| >English has ~1100 million total speakers but only 318
| millon native speakers, while Chinese has 918 million
| native speakers
|
| Why would that matter? Arguably the ideal lingua franca
| should have no native speakers at all as those have an
| unfair advantage.
| CyberRabbi wrote:
| > Why would that matter? Arguably the ideal lingua franca
| should have no native speakers at all as those have an
| unfair advantage.
|
| I share your vision of an explicitly taught universal
| language which gives no group or individual an unfair
| advantage. We obviously need more equality in the world.
|
| From the perspective of trying to maximize how many
| people with whom you are able to communicate, however, on
| a practical basis it matters little whether or not they
| are native speakers.
| [deleted]
| maxwell wrote:
| Your numbers above list 1.132B English speakers and
| 1.116B Mandarin speakers.
| CyberRabbi wrote:
| A larger percentage of mandarin speakers are native
| mandarin speakers than the equivalent statistic for
| English. 918 million native mandarin speakers, 310
| million native English speakers. Native speakers are
| generally better at understand the nuances of language
| than non-native speakers.
| likesfwlaptop wrote:
| Maybe we should sterilize a neighborhood muslim to
| familiarise ourselves with their practises and later we can
| bond over it. (Biden recently said it's none of our business
| but that's just ice-cold)
| luplex wrote:
| This is actually not wrong. China is already very important,
| and its influence is going to grow. Speaking and
| understanding Chinese well is a competitive advantage.
| CyberRabbi wrote:
| I agree. I was applying logic consistently. With 918
| million native speakers, Mandarin is the most natively
| spoken language in the world by at least 2x the runner up.
| gurkendoktor wrote:
| I've learned Chinese for fun. It's great that I can now
| read a few more Go/C++ READMEs on GitHub, but other than
| that, I can't imagine what advantage it has? Maybe there'd
| be one if I came from a poorer manufacturing country?
|
| even China commentators in Western media are often
| completely clueless about the language. If these jobs don't
| require Chinese fluency, then which ones do? And even then,
| it'd be much easier to employ the many, many native
| speakers who emigrate from the PRC.
| em-bee wrote:
| as more people learn chinese, the available labor pool
| grows and these jobs may well require chinese skills in
| the future
| moonchild wrote:
| Sounds like the convention used in some countries for time,
| using e.g. 9h20 instead of 9:20
| jeff-davis wrote:
| Years before 0 or after 9999 are not defined in 8601 (there is
| some attempt to allow for them, but it's not really specified).
| Also, the lexicographic sorting would be ruined (if it isn't
| already by timezones).
| therealmarv wrote:
| Even the xkcd https://xkcd.com/1179/ does not mention or gets
| wrong that
|
| yyyymmdd
|
| is also right and allowed in ISO 8601. Especially useful when you
| add time. You don't e.g. want character ":" in your file name
| 20210226T205418 (local time here)
| young_unixer wrote:
| Tangentially related: I hate GNOME's approach at configuring
| formats.
|
| In their format settings, you have to pick a country and that
| determines the format of dates, time, numbers, and the unit
| system.
|
| Of all the countries, none of them has the sane choice for all of
| the fields, namely: ISO 8601 for dates and times with 24h (no
| AM/PM), metric system (or SI, whatever), and dot as decimal
| separator.
|
| You can have sane dates, but then you have AM/PM in the clock.
| You can have 24h clock, but then you have a comma as decimal
| separator, etc.
|
| Can we add a country "Saneland" with the sensible options for all
| fields? cause that's where I want to be from. Saneland: the
| imaginary place where we use reasonable standards and things
| work.
| akvadrako wrote:
| Probably those are from the locales package?
|
| en-dk is the best one, it is Europe standard english which I
| think fits all your requirements for Saneland.
| Symbiote wrote:
| en-se is slightly closer, as it has an ISO 8601 date, but
| like en-dk it still has a comma decimal separator, and the
| clock has a dot separator (13.49).
|
| An artificial en-xi or similar is probably best: take en-ie,
| and just change the short date format.
| akvadrako wrote:
| en-dk has ISO 8601 though you're right it uses the comma.
|
| https://github.com/lattera/glibc/blob/master/localedata/loc
| a...
| Symbiote wrote:
| That reflects (supposedly) the official standard, but
| even on government forms DD-MM-YYYY or DD.MM.YYYY is
| used. I have never seen the ISO format used outside
| computer systems, unlike in Sweden where it's
| commonplace.
|
| It's inconsistent with da_DK, which uses DD-MM-YYYY.
|
| But there's already the decimal separator bug (writing
| English? dot, writing Danish? comma). %
| en_DK is used outside Denmark, as some sort of generic
| continental % European English locale.
|
| And that's the nasty hack -- this should be defined in
| en_EU or similar.
| akvadrako wrote:
| Right, en_DK has almost nothing to do with Denmark,
| instead it's basically the imaginary Saneland the top
| poster asked for.
|
| I agree en_EU would make more sense, maybe somebody
| should submit a patch to glibc and in a decade it'll be
| safe to switch.
| bombcar wrote:
| Salesforce does the same thing so I tell it I'm Latvia. It
| kinda works until it doesn't.
| cheph wrote:
| XFCE allows you to set a strftime string for date format.
| sebmellen wrote:
| This is one of my biggest gripes with GNOME, along with the
| incredibly stupid lack of thumbnails in the file browser.
| superzamp wrote:
| And the way if forces you into a full-blown file search when
| you start typing letters and are just looking for files with
| that prefix...
| silon42 wrote:
| +1 for a new locale, equivalent to C but with UTF-8, ISO DATE,
| ISO paper, ...
| silon42 wrote:
| Also, Android had until version 5 an option to force ISO
| date/time format, but it was removed for some reason?
| wombatpm wrote:
| Can we petition the government of Null Island (Lat 0, Long 0)
| to adopt the SaneLand defaults?
| bobbylarrybobby wrote:
| The country should be called Esperantonia
| atoav wrote:
| As a european I use ISO 8601 for everything since about 5 years.
|
| One point is also: if you manually write a date, the easiest to
| remember part (the year) comes first, then the month (which is
| usually also easily remembered) and then the thing that you can
| forget at times.
|
| This feels better than the other way around.
| JdeBP wrote:
| I can beat that slightly. I have things with ISO 8601 dates
| written on them, by me, dating from 1986. Yes, I started using
| it before it was formally published as a standard. I initially
| used the basic format.
| wankeler wrote:
| 26 II 2021
|
| Job done
| fmajid wrote:
| Except `YYYY-MM-DD HH:MM:SS` is not the ISO 8601 date format,
| `YYYY-MM-DDTHH:MM:SS` is (note the T). Replacing the T with a
| space is a RFC3339 extension.
| CivBase wrote:
| > If you're smart enough, you've probably also noticed that the
| American one makes no sense and is just awful
|
| That's simply not true. The American format is designed to
| reflect how we normally pronounce dates or write them out in long
| form (eg "September 11th, 2001").
|
| The European format is also flawed. It's similarly divided into
| three tokens (day, month, year) but they are ordered so that the
| tokens represent greater magnitudes of time moving from left to
| right, big-endian-style. The problem is each token is a decimal
| number which is traditionally written in little-endian-style. So
| like the American format, you still need special understanding of
| the format to read dates and they cannot be trivially sorted.
|
| The ISO 8601 format is little-endian all the way through so it is
| trivially sorted. UNIX time is even easier to sort and compresses
| much better, but it's rather difficult for humans to read.
| heurisko wrote:
| > The American format is designed to reflect how we normally
| pronounce dates or write them out in long form (eg "September
| 11th, 2001").
|
| In the UK at least, we don't write or say dates in that order.
| With the exception of September 11th.
|
| I believe it's the same in German, 4te Juni etc.
| joshspankit wrote:
| In my opinion, YYYY-MM-DD is the last unambiguous date format
| left.
|
| I hold the line, and I will die on this hill.
| roelschroeven wrote:
| I wish HTTP would ISO 8601 for its dates, or anything sane in any
| case. Dates in HTTP headers are meant to be machine-readable,
| right? Then why use month names instead of numbers? Why include
| the day name? "Wed, 21 Oct 2015 07:28:00 GMT" is just silly. And
| that's just the preferred format; there are two other formats
| that are just as idiotic that recipients are supposed to
| understand.
|
| https://tools.ietf.org/html/rfc7231#section-7.1.1.1
| tpetry wrote:
| The article is missing one of the best features of iso 8601: it's
| string form is naturally sortable. You don't need any specific
| logic for sorting, so e.g. your filesystem will automatically
| sort files correctly if you prefix them with a iso 8601 date.
| 908B64B197 wrote:
| The standard American date format (MM/dd/yyyy) also somewhat
| has this property for a limited number of use cases.
|
| Sorting within a single year will work, sorting multiple years
| will place the same date adjacent to each other so it makes
| them easy to compare if you are printing out let's say sales
| data.
| emergie wrote:
| Americans using cal/foot/elbow/galon system of measurements
| is quirky, but bearable.
|
| AM/PM thing is silly, but bearable.
|
| Malformed MM[/-.]dd[/-.]yyyy date format is one of the most
| confusing thing I have ever encountered and it generates
| serious problems.
| emj wrote:
| > it generates serious problems
|
| I would say that by just existing it create serious
| problems. You can never be sure if a date if day/month or
| month/day, this was especially bad from year 01 to 12.
| During those twelve years I was a date zealot "there can be
| only ISO 8601".
| petee wrote:
| I think it makes sense only in the fact that we write it
| how we say it out loud - "February 26th, 2021." It is just
| another convention, albeit inconvenient for computers. I
| doubt the british way of saying "26th of February" was done
| intentionally to aid sorting...
| l8again wrote:
| Even though it mentions this in the context of filenames being
| sortable, I agree that this should have been a bullet point of
| its own.
| Markoff wrote:
| that's reason I switched to ISO 8601 in my folders structure
| decades ago, obviously can't use it in regular
| documents/communication in Europe
|
| there used to be similar problem with alphabet (folder) sorting
| though, where Windows used to sort letter CH which goes after H
| in alphabet right within C as if CH didn't exist, but I think
| they sorted it in recent years, though I use English Windows
| and still have this issue, it's quite easy for sorting actually
| since H never follows C in Slovak or Czech language and when
| they are together they always make letter CH, so it should be
| easy to fix for sorting file/folder names
|
| orally we use 12 hours time format even in most of the Europe,
| we just use in digital watch 24hr format
| p_l wrote:
| If document didn't have specified time format, I never had
| issues using YYYY-mm-dd from ISO 8601. And the ones that had
| specified time format were upfront about expected format,
| so...
|
| Would be interested where anyone encountered issues with
| ISO8601 dates
| bonzini wrote:
| English Windows applies English sorting rules, whereby CH is
| not a separate letter. It is not easy at all, different
| languages have different rules, including multiple passes
| over the input (e.g. the first for letters and the second for
| accents), even some of them left-to-right and some right-to-
| left.
| eCa wrote:
| > obviously can't use it in regular documents/communication
| in Europe
|
| What I do when travelling in Europe[1] is to un-ambuigify the
| date by replacing the month number with the English month
| abbreviation: 2021-feb-26. It's non-standard but can't
| reasonably be misunderstood by a human.
|
| [1] I'm from a European country where the ISO 8601 way of
| writing dates is common, and more specifically neither the
| American nor "European" formats are ever used.
| Someone wrote:
| FTA:
|
| _"The elements are always padded to the maximum number of
| digits. This not only makes all of the dates look equally nice,
| but also, coupled with other quirks of this format, allows the
| files with the date in the name to be sorted just by the
| filename."_
| [deleted]
| justsomeuser wrote:
| Also every language has a tag for that format (.toISOString()),
| where as the other formats might require entering your own
| printf spell
| andy-x wrote:
| Only true if you ignore timezones and DST (which most people do
| because it is unholy mess) or stick to UTC.
| mywittyname wrote:
| You don't need to stick to UTC, you just need to stick to a
| single timezone. Which is something that is generally true.
|
| UTC just happens to be a good natural choice for eliminating
| timezones, but I've seen companies chose another tz as their
| standard.
| shpx wrote:
| or until you get into 5 digit years
| aairey wrote:
| NMP. :D
| shpx wrote:
| It can be a problem/nuisance if you're working with
| nuclear waste or orbits.
|
| It's also ironic how programmers are surprised by the
| passage of time when it's one of the only things that's
| truly guaranteed.
| m12k wrote:
| Which is a side effect of being consistent with the way we
| write all other numbers, with the value represented by each
| digit declining as we go left to right.
| jeff-davis wrote:
| Lexicographic sorting does not work for numbers of different
| lengths, e.g. "100" and "9".
| pwg wrote:
| It does if you zero fill the shorter number to an equal
| number of digits: "100", "009".
| koolba wrote:
| There's a special place in hell for people that using
| variable length representations for time units that are
| meant to be consumed by machines.
|
| I think it's across the hall from the room for people who
| configure servers for anything besides UTC.
| btilly wrote:
| Where do you put the people who think that we should
| inflict leap seconds on UTC?
| koolba wrote:
| In a special room resting atop a centrifuge so they can
| spend eternity arguing with each other about how long
| they've been in there.
| JdeBP wrote:
| Is their punishment to be forced to parse "009" with the
| C language's strtoul() library function for all eternity?
| (-:
| boring_twenties wrote:
| What's the problem with strtoul? Just make sure to pass
| 10 as the third parameter, not 0.
| mywittyname wrote:
| Maybe the punishment in hell should be to RTFM for the
| rest of eternity.
| marzell wrote:
| This is my primary reason for advocating yyyy-mm-dd (regardless
| of including hh:mm:ss) in my work environment. I always feel
| it's very simple to explain things like "you can sort by name
| and it's automatically sorted by date" and it's just
| unbelievable the amount of pushback I get. This coming from
| users having trouble finding files from a certain time period,
| as their timestamps might be different due to
| copying/modifying. Also easy to convert to INT (i.e.
| yyyymmdd/20210226) for use as a partition key or FK for a date
| dimension.
| simonlc wrote:
| Most forms are sortable, though dates with a timezone specified
| are not sortable.
| [deleted]
| smiley1437 wrote:
| Great format, but once 2032 rolls around everyone will go back to
| a 2 digit shorthand for the year. Because humans are lazy.
| kstenerud wrote:
| ISO-8601 was a good early attempt, but unfortunately it has some
| negative points:
|
| - Only offset-based time zones are allowed (which are next to
| useless).
|
| - Omitting the time zone defaults to local time, which renders
| the time ambiguous. Defaulting to UTC makes much more sense.
|
| - BC dates are all offset by 1 ("-1" = 2 BC). I know the reasons
| for this, but this could have been moved to the implementation
| and not exposed to the user.
|
| - Lots of silly things like fractional-minutes and multiple ways
| to represent the same data bloat the spec and implementations.
|
| This is why I rejected iso-8601 and developed my own for
| https://github.com/kstenerud/concise-encoding/blob/master/ct...
|
| Examples:
|
| 2019-8-5 : August 5, 2019
|
| -300-12-21 : December 21, 300 BC (proleptic Gregorian)
|
| 12:05:50.102 : 12:05:50 and 102 milliseconds UTC
|
| 4:00:00/Asia/Tokyo : 4:00:00 Tokyo time
|
| 2019-01-23/14:08:51.941245 : January 23, 2019, at 14:08:51 and
| 941245 microseconds, UTC
|
| 1985-10-26/01:20:01.105/America/Los_Angeles : October 26, 1985,
| at 1:20:01 and 105 milliseconds, Los Angeles time
|
| 25192-11-01/03:00:00/48.86/2.36 : November 1st, 25192, at
| 3:00:00, at whatever is in the place of Paris at that time
| (global coordinates 48.86, 2.36)
| kitd wrote:
| The real purpose of endianness which is missed here is the
| ability to sort. Sorting a list of iso8601 dates alphabetically
| means sorting them chronologically too.
| [deleted]
| k_sze wrote:
| Until we hit year 10000, but yeah, that's still a looong time
| to go.
| est wrote:
| There's some proposal that this year 2021 is actually 12021,
| to make the year neutral of some specific religious event.
| ComputerGuru wrote:
| I know you're not saying you are encouraging it and it's
| just a related but of trivia, but I find that hilarious.
| Because when someone asks "why start there?" the answer
| "it's a thousand years before Jesus Christ was born, the
| millennium heralding his arrival" is better?
|
| (I'm not even Christian but I also don't have a chip on my
| shoulder and can accept its influence on the world)
| bhaak wrote:
| It's _ten_ thousand years before the assumed (but likely
| wrong) birthday of Jesus Christ, to have a positive date
| for all written human history (well, until we find the
| archives of Atlantis) and an easy round offset for the
| prevalent human calender in use.
| grey_earthling wrote:
| The answer is "because -10000 CE is an approximation of
| the beginning of human civilisation, using this epoch
| removes negative year numbers from all historical dates,
| and it's simple to convert from the ubiquitous CE epoch".
|
| https://en.wikipedia.org/wiki/Holocene_calendar
| TeMPOraL wrote:
| Yup. I have a calendar for 12021 hanging in my office, and
| I very like the sentiment it expresses. I tried to use the
| Holocene years with other people, but they remain
| unconvinced.
| mattashii wrote:
| ... which is funny, because the gregorian calendar is
| supposedly based on a compromise between some years that
| christ was supposedly born in (the chosen year 1 is none of
| those, according to research, as he was born in 6-4 BC
| [0]).
|
| So now we have: another calendar, that has a starting year
| that is defined by subtracting an arbitrary number from a
| compromise between alledged years some person was born in.
|
| I love how humanity has the capability to invent new things
| with increasing complexity.
|
| [0] https://en.wikipedia.org/wiki/Anno_Domini#Birth_date_of
| _Jesu...
| eesmith wrote:
| It's there:
|
| > This not only makes all of the dates look equally nice, but
| also, coupled with other quirks of this format, allows the
| files with the date in the name to be sorted just by the
| filename.
|
| My issue is with:
|
| > Simplified, the core date format looks like this: yyyy-mm-dd
| hh:mm:ss
|
| Here are the examples at https://en.wikipedia.org/wiki/ISO_8601
| 2021-02-26T06:22:59+00:00 2021-02-26T06:22:59Z
| 20210226T062259Z
|
| Note the "T" instead of a space between the date and time?
| That's what the spec says:
| https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_tim...
| . "Separating date and time parts with other characters such as
| space is not allowed in ISO 8601, but allowed in its profile
| RFC 3339."
|
| Note the optional use of "-" and ":"? That's "basic" vs.
| "extended" formats.
|
| Plus the optional timezone specifier (if not present, assume
| it's the same timezone).
|
| There's also optional support for microseconds.
| kirbykevinson wrote:
| I omitted this detail on purpose to not distract the reader
| who doesn't know much about date formats.
| eesmith wrote:
| How would you describe the accuracy and veracity of
|
| > "Here there's only one correct way to write a date,"
|
| given that there are multiple correct ways, and the way
| shown wasn't actually ISO 8601 but RFC 3339?
| kirbykevinson wrote:
| Yes, technically there are some edge cases where you can
| write things differently (apart from what you mentioned,
| one is, for example, writing the UTC time zone by Z vs
| +00:00 and another is adding additional precision to the
| date), but for the end user it's basically the same.
| Let's not ruin the illusion here :)
| eesmith wrote:
| There's nothing wrong with leading with something like:
|
| ISO 8601 is a complex specification because of the many
| different ways to describe times, dates and duration.
| Don't let that complexity throw you off! The ISO 8601
| timestamp format is clean and elegant. These examples
| will use the widely used ISO 8601 profile known as RFC
| 3339, which I'll refer to simply as "ISO 8601".
|
| No need for an illusion when synecdoche works.
| mjevans wrote:
| I loath the T and Z characters, so respectively I use a
| single dash (Between the date and time) and no Z; for time I
| often leave in the colons (:).
|
| Example: 20210226-00:01:25 this presents the data in a format
| I can easily visually parse and also easily search for useful
| things in log files with.
|
| When parsing such a date I tend to throw out all of the
| characters, but the 'Zulu' or timezone at the end probably
| should be parsed in anything that isn't a trivial internal
| use.
| bhaak wrote:
| I find it impressing that you can easily parse
| 20210226-00:01:25.
|
| The time is of course no problem but even with "20210226"
| standalone, I stumble and misread 10 and 22 before noticing
| that this doesn't parse. If there are more zeros and more
| 1's or 2's, it gets even worse.
|
| I hate it that the migrations in Rails are numbers only.
| "db/migrate/20210218125920_add_new_column.rb" is simply not
| human parseable.
| apricot wrote:
| When I visited China, I saw 11-digit phone numbers
| commonly written without any punctuation or spaces: like
| 12020569031. I guess you can get used to it.
| eurasiantiger wrote:
| In other words, you are not using a standard format.
| mjevans wrote:
| I think of it as a modified form of the standard format,
| where the standard format doesn't fulfill the needs of my
| use case.
| guiraldelli wrote:
| Spot on: I came here to make this comment about ISO 8601 vs.
| RFC 3339 and point-out that "European format" is a
| generalisation, not a rule: Lithuania [1] and Sweden use the
| ISO 8601 for date representation, and Portugal and Spain uses
| dd/mm/yyyy.
|
| I must say I just saw the dd.mm.yyyy used in Italy, but it
| seems that a few other countries also use it.
|
| (And EU requires dd/mm/yyyy in "best before" dates.)
|
| Besides this nitpicking, I agree with the author for several
| years already.
|
| [1]: https://en.wikipedia.org/wiki/Date_format_by_country
| tom_mellior wrote:
| > (And EU requires dd/mm/yyyy in "best before" dates.)
|
| This sounded intriguing, so I checked my fridge, and this
| doesn't seem to be strictly true. Everything I found used .
| rather than / as the separator, as is usual here (Austria).
| But also, some years were YY only. And the eggs are just
| plain weird: Both the carton and the stamp on the eggs list
| DD.MM. while the graphic explaining the date stamp uses a
| DD.MM.YYYY example date.
| mjevans wrote:
| That's also the only time (full) European dates make sense,
| when writing them on the right hand side of a ledger page so
| that the exterior of the ledger / book is indexed with the
| largest components on the edge of the page.
|
| US dates only make sense if you don't care about the year and
| are writing on the left most side of a page; that might make
| sense if ink or paper is at a premium.
| orwin wrote:
| My great great grandfather wrote a book about this 120 years
| ago! And yes, it was for taxes and accounting.
| m463 wrote:
| I was going to say this is a lot more readable than that other
| date/time format: 2021-02-26T12:25:04Z
|
| or 2020-01-30T03:14:15+05:00
|
| but turns out its the same one
| wodenokoto wrote:
| People look at ISO-8601 and think year-month-day looks great! But
| don't realize that it also includes thing like --month-day (yes,
| you don't need to include year to have a valid iso date!) year-
| week, year-day and lots of other things.
|
| So I would generally advise against accepting iso formatted dates
| and instead decree a single date format.
|
| https://en.m.wikipedia.org/wiki/ISO_8601
| tuukkah wrote:
| > _The 2000 version allowed writing "--04-05" to mean "April
| 5"[23] but the 2004 version does not allow omitting the year
| when a month is present._
| makach wrote:
| It's time to come clean, I love you ISO8601 and I always have.
| You complete me.
| rollulus wrote:
| At the risk of nitpicking, I prefer RFC 3339, which is a profile
| of ISO 8601. ISO 8601 provides room for things you typically
| don't want, e.g. dropping time zone offsets.
|
| While I'm typing this I realise that I've never actually read the
| ISO 8601 spec, like probably most people here, because it's not
| free. I cannot even be sure it really exists.
| taylodl wrote:
| Every time there's a discussion on date/time formatting I
| always refer people to RFC 3339
| (https://www.ietf.org/rfc/rfc3339.txt).
|
| Learn it, live it, love it!
| CuriousNinja wrote:
| > never actually read the ISO 8601 spec ... because it's not
| free
|
| I was very surprised to discover this. Why are they charging
| money for the specification of a date format? I would expect
| standards like these to be published in public domain.
| kube-system wrote:
| ISO finances their operations by selling documentation,
| subscription from members, etc. The point of ISO standards is
| to facilitate international trade. The intended audience for
| these standards are large multinational companies.
| ska wrote:
| Pretty much all the standards bodies I know of are financed
| through sales of the standards documents. It's not a bad
| system, in the end the commercial entities who end up needing
| them most pay for their development and upkeep.
| JdeBP wrote:
| Aside from the fact that you are conflating copyright with
| price, note that many standards organizations charge money
| for copies of their standards documents.
|
| ISO charges roughly 20 times the price of a paperback book
| for a 33 page document. You can buy BS/ISO 8601-1:2019 from
| the BSI for an even more exorbitant PS246. Standards
| Australia will sell the older 2007 version to you for a mere
| AUD165.
|
| But this is not special. _All_ standards documents cost money
| from these organizations, from dates and times to electrical
| plugs. Treasure the fact that you can (for example) get
| (some) ECMA standards from ECMA for free. It isn 't the norm.
| dfox wrote:
| I have read the actual ISO 8601 spec. It is somewhat typical
| wall of prose ISO standard that contains meaningful conformance
| distinctions which depend on two words in the middle of 10+
| line paragraph.
|
| For me, more significant reason to prefer RFC 3339 constrained
| profile is that ISO 8601 does not only mean YYYY-MM-
| DDTHH:MM:SS.sss but also includes bunch of alternate syntaxes
| like YYYY-DDD. And I have one big issue with RFC3339: there are
| cases when the "don't care about timezone" ISO 8601 syntax is
| actually useful.
| [deleted]
| SideburnsOfDoom wrote:
| > I've never actually read the ISO 8601 spec, like probably
| most people here
|
| Indeed. The comprehensive Wikipedia article on ISO8601 is as
| far as we go
|
| https://en.wikipedia.org/wiki/ISO_8601
|
| Thanks for pointing out rfc3339 - this appears to be the
| "useful part" of ISO8601 for data interchange.
|
| https://tools.ietf.org/html/rfc3339
| wongarsu wrote:
| Draft versions of the ISO standard are easy enough to find on
| the internet. But the Wikipedia article is excellent and
| covers just about everything.
| diggernet wrote:
| Yes, and I've read the drafts of ISO 8601-1:2019 and
| 8601-2:2019. But can I rely on them? They were published in
| 2016. What has changed between then and the official
| release in 2019?
|
| Also, neither RFC3339 nor Wikipedia discuss features like
| open-ended time intervals. They are in the draft, but did
| they make the final cut? And in what form? No idea...
|
| The closest I've found to "official" documentation of the
| 2019 update is a short summary of the changes, hosted by
| Library of Congress[1]. Which is nice to have, but I sure
| wish the real standard was public.
|
| [1]https://www.loc.gov/standards/datetime/
| systemvoltage wrote:
| No one here is talking about practicality for non-software
| engineers which is probably 99.9% of the population. It might be
| fine for sorting and no one gives a shit about endianess. Common
| person would argue - why do they need to know the year first?
| Most people encounter dates in the same year, they already know
| we're in 2021 and it is not as important. Having to laboriously
| parse YYYY before getting to the most important bits, either
| month or day depending on what they're trying to do; doesn't seem
| too practical. I hate writing ISO 8601 dates, even though I
| _know_ it is logical.
|
| Not everything logical works with humans. In my day to day life
| (not engineering use), I personally prefer inches and feet, they
| are just human scale dimensions. Conversion happens less often
| than you think - most people convey to others that this box is
| 12x8x8 inches. Conversion from inches to feet happens way less
| often. I hate fractions though. It would be great if a centimeter
| was twice as long in physical dimensions. It's just too granular
| and falls in an uncanny valley. And no one uses decimeter (10 cm)
| for some reason which is actually nice since it is roughly the
| size of the index finger.
| bhaak wrote:
| > I hate writing ISO 8601 dates, even though I know it is
| logical.
|
| Nobody forces you to write ISO 8601 dates but if you want your
| dates to be easily parseable by humans, why would you write
| them all in numbers?
|
| 3 Nov 2020, 3rd November 2020, Nov 3rd 2020, even something
| like 2020 Nov 3 is uniquely parseable by humans. Even if the
| human doesn't know the language of the month, they can still
| find out what date it is from a Google search.
|
| With 3/10/2020 you _never_ know for sure what date it is.
|
| > I personally prefer inches and feet, they are just human
| scale dimensions.
|
| Meter, centimeters, and millimeters are human scale dimensions,
| too. Just because you didn't grow up with them doesn't make
| them non-human.
| systemvoltage wrote:
| Not sure, I grew up in two countries, one metric and one
| english units. I still prefer inches and feet to describe
| length. I would like decimeter but no one uses it.
| bhaak wrote:
| This came up in a r/AskEurope thread and at least some
| slavic countries use decimeters.
|
| But that's the beauty about easily convertable units. Even
| if other people use other conventions, the mental process
| to convert them is almost zero.
|
| Just imagine somebody giving their height just in inches
| instead of the usual feet and inches?
|
| Could you mentally parse what 76 inches are?
|
| I guess you have basically no problem with 193cm, 1.93m ,
| or "one ninety-three", or even 19.3dm.
| systemvoltage wrote:
| Agreed, and needless to say, I use metric system at work
| (engineering).
|
| Now only if we evolved to have 12 fingers, we would have
| a supercharged metric system in duodecimal (base 12). Far
| superior to the decimal number system we use today.
|
| https://en.m.wikipedia.org/wiki/Duodecimal
| bhaak wrote:
| Well, one of the oldest known systems was already very
| good. Alas, the Babylonian numeral system didn't
| completely make it down to us unfortunately.
| rswail wrote:
| English/Australian people used to (still do?) measure
| their weight in stones and pounds. The average man was
| "13 stone" which is 182 pounds.
|
| US people measure their weight in pounds, 182lb
|
| So yes, a USian telling their weight to a UKian would be
| like saying their height in inches.
| EdwardDiego wrote:
| Kiwi here, we generally only use pounds for the weight of
| a newborn, unsure why.
|
| We also tend to still refer to height informally in feet
| and inches.
|
| That's about our only remaining usage of imperial units
| apart from inches in penis size. We refer to a serving of
| beer between 425mL to 468mL as a pint, but it's only a
| descriptive term and not a legal measure.
| bambax wrote:
| > _laboriously parse YYYY_
|
| Really? It's hard to parse the year??
|
| What about when you come across a piece of paper written some
| time ago, is it not useful to know the year?
|
| > _most people convey to others that this box is 12x8x8 inches_
|
| "Most people" == nobody outside of the US.
|
| > _And no one uses decimeter (10 cm) for some reason which is
| actually nice since its the size of the index finger_
|
| I just measured my index finger. It is 8.45 cm.
| systemvoltage wrote:
| > most people convey to others that this box is 12x8x8 inches
|
| Replace inches with cm, I didn't explain it well. Even if it
| is centimeter, people would _tell_ dimensions to others
| _more_ than _convert_ them. The point was about _frequency_
| of communication between humans vs. _frequency_ of converting
| units.
|
| You seem to be taking offense that I said something US-
| centric. I didn't mean that at all.
| ben509 wrote:
| > Really? It's hard to parse the year??
|
| Is it so hard to write "it is?" Nevertheless, you used a
| contraction.
|
| You did so entirely unconsciously because that's how langauge
| works.
| alkonaut wrote:
| No. Every human likely encounters date sorting at some point.
| And feet and inches aren't really any more human or natural
| than 4x5x2 dm or 40x50x20cm. Dividing by 10 isn't more human
| either, but adding/removing zeroes or moving a decimal point is
| certainly easier for the human brain.
| systemvoltage wrote:
| Is dm used widely wherever you're located?
| alkonaut wrote:
| Its a pretty clumsy measurement so perhaps not "frequently"
| but it's widely used yes (Scandinavia). For example windows
| and doors are standardized in dm, so a typical window is a
| 11x13 and a door is 9x21. It's going to have some other
| measurement in reality like 1120x1310mm but the dm
| measurement is still used to reference the rough size.
| progval wrote:
| It's not just about years, and it's already explained in the
| article. When I see the date "02/03" or "02/03/2021", I can't
| tell if it means "March the 2nd" or "February the 3rd", because
| websites and software don't consistently detect (or even care)
| about my locale.
|
| But if the software show 2021-03-02, I unambiguously know which
| it is.
| systemvoltage wrote:
| Point noted.
|
| We weren't so globally connected just 20 years ago, so if you
| were in US, you were used to MM/DD format and if you were
| anywhere else, you were used to DD/MM format. It was all
| local.
| JdeBP wrote:
| Nonsense. People have been commenting on how these two
| orderings are confusing for _far_ longer than 20 years.
| Things made in the United States have had worldwide
| circulation for quite a while, now. Even if one has WWW
| tunnel vision, Markus Kuhn 's WWW page on ISO 8601 has been
| around since 1995.
| [deleted]
| fermienrico wrote:
| If you're living in Berlin, it didn't matter what US date
| format was 20 years ago. You're missing the point that
| the globe is far more connected due to the internet.
| JdeBP wrote:
| No, _you_ are missing the point that the globe was
| connected due to the Internet for far more than 20 years,
| as evidenced _at least_ by the fact that one of the more
| widely known treatises on ISO 8601 on the World Wide Web
| dates from the middle 1990s. And that 's _merely_ the
| World Wide Web, not the worldwide computer networks and
| communications systems, where dates have been an issue,
| that pre-date the WWW. The idea that this issue is _new_
| because the world only got connected in the 21st century
| is baloney. Doubly so: The world got connected so that
| people in other countries saw each other 's conventional
| date formats long before, and people have been discussing
| date format ambiguities for _far_ more than 20 years.
| cm277 wrote:
| I tried to push ISO to my (US/EU) company many times... it just
| doesnt work because you only need YYYY once in a while.
| Instead, we've settled on NATO formats (another US+EU org): 3
| Nov 21 or just 3 Nov. It's unambiguous and short --yes, harder
| to parse and sort, but those are computer problems, always
| easier to solve than human problems...
| Andruru wrote:
| "3 Nov" is ambiguous, it could mean 2020-11-03 or 2021-11-03,
| or any other year. And by the way, "3 Nov 21" is also
| ambiguous, it could be 2021-11-03 or 1921-11-03. Lots of
| stuff happened in 1921.
| trinix912 wrote:
| Also, "3 Nov 21" works only as long as everyone speaks a
| language in which "Nov" actually stands for November.
| Abbreviations can have false friends in some languages.
| It's the reason most EU personal documents try to avoid
| using text as much as possible because it's impractical to
| write it in 20+ languages.
| jpetso wrote:
| Bah, humbug. I moved to Canada almost a dodecade ago and
| despite all person heights and interior design stuff being
| denominated in imperial units, getting the hang a grasp of any
| multiples is no more intuitive than in metric units. Metres
| work similarly well as feet, that is, not great for nontrivial
| amounts.
|
| Within a certain range you'll do fine either way. Outside of a
| certain range you'll always need a measuring tape, or you just
| had a had a lot of practice, eyeballing and learned habits
| going in.
| guerrilla wrote:
| Europe and China disagree with you.
| wahern wrote:
| 30 years ago when most literature was either published recently
| (newspapers, magazines, etc), or the date of publication was
| mostly irrelevant (books), your argument makes sense. If you
| cared at all, what mattered was usually the month and day.
|
| For most of the literature people read in the 21st century,
| especially this past decade, the year is the most important
| part. People normally couldn't care less whether something was
| published 3 days ago or 3 months ago. But knowing whether it
| was published 3 years ago makes all the difference in the world
| to its relevancy.
| systemvoltage wrote:
| I think I need to labor on my point a bit more.
|
| There are many use cases for dates. From publication date to
| planning vacation on a calendar. What is the _most common_
| use for a date? Calendar, I guess? The most _frequently_ used
| dates we encounter are within + /- weeks from now. In a day
| to day use, YYYY is useless.
| anjbe wrote:
| By far the most common use I have for dates is filling out
| forms. In those cases the year is almost always essential.
|
| Speaking from personal experience, even an American can
| make an effort to use YYYY-MM-DD in any situation asking
| for a numeric date, and almost always succeed. The biggest
| exceptions are forms asking for MM/DD, and online payment
| forms asking for credit card expiration as MM/YY.
| wahern wrote:
| A calendar is a great example because they usually
| emphasize the month, week, and day _graphically_ , not
| _typographically_.
|
| Another common remaining example might be a bank statement.
| But what's interesting there is that the dates are in a
| column and the year disappears. It hardly matters whether
| the year comes first or last because you don't actually
| notice it at all unless the year is rolling over--
| conspicuous change in that column.
|
| But when I'm looking at something lacking implicit context
| regarding publication date, such as an online magazine
| article, a YouTube video, or a Tweet, the year is the first
| thing I'm searching for. Even on HN, the rule is that the
| year needs to be included in the title if it wasn't
| published in the current year.
|
| I guess for e-mail the day and month are most important
| (similar to bank statements), unless you're reading really
| old messages. But I use mutt with a default mailbox view
| that doesn't even show the year.
| saithound wrote:
| These "arguments by practicality " are almost always just-so
| stories.
|
| The Hungarians (and presumably the Chinese) have their own
| just-so stories about why YMD is the most practical order: you
| use dates mostly when you sort heating bills, invoices, or even
| fruit preserves, and in all those cases you need to sort by
| year first.
|
| Australians will tell you a tale about how "day before month"
| is human-scale, while "month before day" is not. Heck, ask a
| German why the decimal comma is superior to the decimal point,
| and you'll hear plenty of practical-sounding reasons. French
| carpenters will tell you how they use decimal units because
| those are much more practical than inches. British people will
| explain how left-hand traffic is the only practical choice
| (6a41ef).
|
| People are much better at confabulating reasons for sticking
| with conventions than they are at telling practical and
| impractical conventions apart. Indeed, if there was one
| obviously practical choice, there would be no differing
| conventions for ISO standards to reconcile.
| akalsz wrote:
| I believe that these conventions (at least for dates) are
| indeed the most practical for their respective languages.
|
| Take for example "October the third, two thousand nine"
| (10/3/2009, MDY). In German one would pronounce this as "der
| dritte Oktober zweitausendneun" (3.10.2009, DMY). In
| Hungarian "ketezer-kilenc oktober harmadika" (2009. 10. 03.,
| YMD). All of these pronunciations reflect the order numerical
| dates are written: using any other convention would simply
| make them less natural to pronounce.
|
| Now it is certainly not unheard of that the order of
| pronunciation also changes (see the British "the third of
| October"), but changing language is a lot harder in some
| cases impossible without breaking grammar than changing
| written numerical representations.
| systemvoltage wrote:
| This way we can never reach consensus and beat about the
| bush! Welcome to the bike shed. What color should we paint it
| with?
| tom_mellior wrote:
| > The Hungarians (and presumably the Chinese) have their own
| just-so stories about why YMD is the most practical order:
| you use dates mostly when you sort heating bills, invoices,
| or even fruit preserves, and in all those cases you need to
| sort by year first.
|
| I should note that the Hungarians (can't speak for the
| Chinese) _obviously_ leave out the year when it 's clear
| which year is meant.
| atleta wrote:
| Speaking for the Hungarians: you're right, if you get used to
| it, you actually don't even notice the leading year if you
| don't care. The whole thing just seems to be made up. In
| other words, rationalization of a habit.
|
| Why big endianness is great though, in practice is that most
| of the time you actually do care about the year when you use
| the written form AND it's unambigous. The problem with the
| reverse notations is not that it seems illogical to some
| people. The problem is that both d/m/y and m/d/y is used and
| you can't have the faintest idea which one you are looking
| at.
|
| Now in theory we could have y/d/m, but we fortunately don't,
| so seeing the first number being a 4 digit one, you know how
| to interpret the date.
| kalleboo wrote:
| > _Not everything logical works with humans_
|
| Works fine for the Chinese and Japanese, and last I checked
| they were humans.
|
| American English already has this weirdness elsewhere - the
| $-sign in $15 is read in the "wrong" place and always trips me
| up when I'm reading something out loud but others will defend
| that practice to the death
| apricot wrote:
| My C/2: you are %100 right.
| pimlottc wrote:
| The alternate I like to use on forms and such when I know it's
| likely going to be read by a human is "DD Mon YYYY", e.g.
| 1 Feb 2021
|
| This is a bit more human-readable and closer to commonly-used
| forms of dates while still being completely unambiguous.
| qayxc wrote:
| > This is a bit more human-readable and closer to commonly-
| used forms of dates while still being completely unambiguous.
|
| A bit more human readable you say? So 1 fev 2021, 1 Lut 2021,
| or 2021 fbryr1 are readable to you? I don't know but to me
| that's just US-centric thinking all over again.
| citrusybread wrote:
| >2021 fbryr1
|
| I was going to ragequit at you for copy+pasting something
| into google translate, as it's shubaT not fbryr.
|
| but TIL, only in the Levant do we say shubaT apparently.
| pimlottc wrote:
| That's true, but as I said, I just use this in certain
| human-read contexts, e.g. paper forms. Which in my part of
| the word are normally in English.
| rswail wrote:
| I worked on a system once that failed in Sweden when we
| changed the locale from US.
|
| Someone was getting the date as 01MMMYYYY and using it as a
| partition name. When the first day of the tenth month
| happened, everything broke, because it was expecting OCT, not
| OKT.
|
| Unambiguous but wrong.
|
| With humans reading it, either you need to be unambiguous, so
| use yyyy-mm-dd, or you don't have to be, so use a format that
| most of your audience will understand.
| knorker wrote:
| Meters are "human scale". To say not is nonsense.
|
| And 3/2. Is that the future or the past? No way to know. Did
| you miss the meeting, or is it next week?
|
| "No one uses a decimeter"... What bubble do you live in? But
| please, lecture some more about cultures you don't understand.
| systemvoltage wrote:
| I've never read anywhere on any product dimensions written in
| decimeter. Show me one and prove your point.
| knorker wrote:
| Show me a tv measured in cups.
| lifthrasiir wrote:
| I think you have a valid point which is irrelevant to ISO 8601
| however. You may be right that common dates are in the same
| year, but such dates would be most conveniently written
| _without the year number at all_. If you need to write the year
| to your date, either because it 's not the current year or it's
| consistent with other dates with the year number, then the year
| number is significant and all arguments against ISO 8601 breaks
| down.
| m_eiman wrote:
| While on the subject of time, could you Americans pretty please
| stop believing that the week starts on Sunday? It's just as wrong
| as your date format.
| Turing_Machine wrote:
| "Americans" didn't invent that idea.
|
| The Hebrews did -- a long, long, long time ago.
|
| Sunday is the first day of the week in almost all of the
| Americas, Japan, South Korea, and China.
|
| Monday is the first day in Europe and some (relatively) recent
| European colonies (e.g., India).
|
| The numbering of the days of the week is purely arbitrary. It
| makes no sense to claim that a particular ordering is "wrong".
|
| If one goes by the sheer number of people who use a particular
| numbering, Americas + China comfortably exceeds Europe + recent
| European colonies.
| globular-toast wrote:
| Any choice is arbitrary. What is a week to the solar system?
| The only things that are real are days and years.
| augustk wrote:
| International Fixed Calendar is an alternative.
|
| https://en.wikipedia.org/wiki/International_Fixed_Calendar
| gherkinnn wrote:
| What is a day in the solar system? What is anything anywhere
| anyway?
|
| That's not the point.
|
| The point is that in the US people typically work Mon-Fri and
| loaf around Sat-Sun (weekend) and yet the week starts in
| Sundays.
|
| It's infuriating.
| globular-toast wrote:
| What practical difference does it make to you? The week
| starts whenever you decide it starts. Would it annoy you
| even more if I decided to start my week on Thursday?
| JdeBP wrote:
| It used to be common for the academic week to begin at
| noon on Wednesday. So that's not as unlikely an idea as
| one might think.
| gherkinnn wrote:
| Feel free to live on a 9 day schedule.
|
| The practical difference is that inconsistent calendar
| representations make them a pain to use.
| Turing_Machine wrote:
| A day corresponds to an actual rotation of the Earth, i.e.,
| a day-night cycle.
|
| A year corresponds to an actual revolution of the Earth
| about the Sun, i.e., seasons.
|
| A week corresponds to...nothing. Four of them are a (very)
| rough estimate of the phases of the moon, but that's not
| something that really matters to anyone other than sailors
| nowadays.
| jpetso wrote:
| Well, the Bible says that you shall rest on the seventh day
| of the week, which in certain religions is known as Sabbath
| or Shabbat or whatever, which as we all know maps to
| Saturday. Without having really done the research, I've
| been ascribing the US calendar idiosyncrasy to religious
| influences... and really, that's what Europe does as well,
| they just picked a different mapping.
|
| So now when we rest, both the Jews and the Christians get
| their favorite day off and yay, we have a two-day weekend.
| gherkinnn wrote:
| If your weekend is Fri-Sat then by all means start your
| week on Sunday.
| DZittersteyn wrote:
| It makes sense to me that the weekend comes at the end of the
| week, but then again, I don't know what came first, the term
| "weekend" or the convention of Sunday being the start of the
| week in some countries
| globular-toast wrote:
| I think it's just one of those things that doesn't really
| make sense to anyone, but one way makes _slightly_ more
| sense to some than others.
|
| In reality there is no week end. The only periods that
| exist are days and years (and lunar cycles). Weeks are
| artificially constructed and it can begin and end whenever
| we want. I can see the sense in saying the week ends at the
| end of Sunday so the weekend is the bit before that. I can
| also see the sense in saying the week ends at the end of
| Saturday and the weekend is around that.
| euroderf wrote:
| Starting weeks on Sundays has the ill effect of centering every
| calendar page on the work week, with the work-free days
| relegated - nay, shoved out - to the margins. The cynic in me
| says this is by design. Perhaps a capitalist plot to denigrate
| time away from work? It would be psychologically satisfying to
| have every calendar week begin on a Monday so that every work
| week ends with a prominent, uninterrupted two-day block of
| work-free time.
| JdeBP wrote:
| It is a capitalist plot with a time machine, given that the
| convention goes back for millennia.
| yokaze wrote:
| China and Japan have Sunday as the first day since the 4th and
| 8th century respectively: http://chartsbin.com/view/41671.
|
| So presumably, you come from a Europe-centric view:
| http://chartsbin.com/view/41671
| InfiniteRand wrote:
| Interesting context for this on Wikipedia
|
| https://en.wikipedia.org/wiki/Chinese_calendar#Week
| FooBarWidget wrote:
| China does? I'm Chinese and I'm pretty sure Chinese consider
| Monday to be the start.
| yokaze wrote:
| Ah, sorry. Then I am misinformed. The locale "zh_CN" does
| give me Sunday as the first, which seems then misaligned
| with actual practice.
| Turing_Machine wrote:
| Not according to:
|
| https://unicode-org.github.io/cldr-
| staging/charts/38/supplem...
|
| Note that common usage and the official definition may well
| differ. Most Americans probably consider Monday the "first
| day of the week" as it is the first day in a standard work
| week. But _officially_ , Sunday is the first day of the
| week.
| rswail wrote:
| Which is weird, because "god rested on the seventh day"
| and the Christian religion believes that to be Sunday, so
| it is the last day of the week.
|
| Why does the US think that the week _starts_ on Sunday?
| InfiniteRand wrote:
| No, the 7th day from Genesis is Saturday, and Saturday
| was the proper day for the Sabbath before Jesus. Sunday
| became the holy day of rest in recognition of Jesus's
| resurrection on Easter. That's at least the standard
| Christian interpretation that I've heard.
|
| I've read some historians state that Christians started
| using Sunday as their Sabbath day in order to distinguish
| themselves more sharply from the Jews.
|
| There are some Christian denominations which use Saturday
| as their Sabbath day, such as Seventh-day Adventist
| Church, so using Saturday as the holy day is a minority
| practice among Christians but it's a significant
| minority.
| gherkinnn wrote:
| The problem is that the US directs how much of my software is
| built.
| bartvk wrote:
| Don't you just use localization features of your API for
| this?
|
| I'm an iOS developer, and whenever I print dates, I just
| ask the system to print it, according to the system its
| locale.
| m_eiman wrote:
| Many developers do not. Especially month views tend to be
| hardcoded.
| em-bee wrote:
| historically europe also started the week on sunday as per
| christian tradition. i too grew up with the idea that the
| week starts on sunday.
|
| this change to starting the week on monday is therefore a
| recent development.
|
| same in china btw. days in china are numbered. monday is
| number 1, and sunday is 7. so while people may have the idea
| that the week starts on sunday (i don't know) the day
| numbering suggests that it actually starts on monday.
|
| same goes for europe. monday by law and sunday by tradition
| yokaze wrote:
| > sunday is 7
|
| My understanding is that all days except Sunday "week-day"
| (Xing Qi Ri ) are numbered. Monday is (Xing Qi Yi ) "week-
| one". So there is still some room for ambiguity left if you
| allow for counting from 0.
| stochastimus wrote:
| The unmentioned benefits: it is fixed-width and follows most to
| least significant parts left-to-right. What this means is that
| the significance of the parts follows the same L-R convention as
| numbers, making it intuitively obvious which is the month and
| which is the day. Oh, and a simple string sort will sort
| timestamps correctly - very handy at the command line. Even db
| columns holding timestamps as strings will get the ordering right
| by default.
| mdeck_ wrote:
| Both of these points are mentioned in the article.
| tom-jh wrote:
| I use the 2021-02-26 format for every place that asks for a date
| without a clear format. All legal contracts, forms, email etc,
| across US and Europe. Never got any trouble for it - it seems
| people readily understand the format even if they may think it's
| a bit unusual.
|
| I wish it was the norm.
| SecurityLagoon wrote:
| Yeah, I deal with so many different countries that it is a
| minefield using any other date format than RFC3339/ISO8601. I
| have been stung by having my birthday month and day inverted a
| few times when using DD/MM/YYYY format.
| aib wrote:
| This has been my experience as well.
|
| Sometimes I tell onlookers that it's an ISO standard.
| itcrowd wrote:
| I have recently been inviting my American colleagues to meetings
| using times-as-American-dates format. In other words, proposing
| meetings to be on 02/26/21 at 25:23 (This example meaning
| February 26th 2021 at 25 minutes past 23 hours).
| kinard wrote:
| I agree with this statement. We've started using it in our API
| calls.
| BoppreH wrote:
| I have a question for the timezone crowd: why does the ISO 8601
| format include a UTC offset like "+09:00" instead of a more
| useful region name like "Asia/Tokyo"[0]?
|
| Take for example the timestamp "2025-07-20 13:30:00+09:00":
|
| - If it was supposed to represent a meeting in Asia/Tokyo and
| that region changes offsets (DST or political reasons), we don't
| have enough information to update the timestamp because it could
| also have been Asia/Seoul or other.
|
| - If a leap second is subtracted at 2025-07-20 13:30:01+09:00,
| we'll see that timestamp twice and it's now ambiguous which
| moment it refers to.
|
| - If a leap second is added at 2025-07-20 13:29:59.9+09:00, we'll
| never see that timestamp and now it's not a valid moment anymore.
|
| - Because of the regional offset changes and leap seconds between
| now and then, I can't reliably subtract that date from any other
| date to calculate durations.
|
| I'm struggling to think of a situation where this timestamp
| format is the correct one.
|
| Why don't we have "2025-07-20 13:30:00+09:00[Asia/Tokyo]" or even
| just "2025-07-20 13:30:00 [Asia/Tokyo]"?
|
| [0]: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
| kerblang wrote:
| OK I'm game... maybe I'll learn something
|
| > - If it was supposed to represent a meeting in Asia/Tokyo and
| that region changes offsets (DST or political reasons), we
| don't have enough information to update the timestamp because
| it could also have been Asia/Seoul or other.
|
| I don't store timestamps in ISO; I use them for communication,
| then parse and store them as epoch time. So if the regional
| offset changes, the epoch time doesn't. In theory, that epoch
| time is _absolute_ and I can display it localized to anybody 's
| preferred locale later.
|
| In that light, adding/substracting seconds is just
| adding/subtracting seconds, although I'm usually passing that
| work off to a date library, which I hope accounts for skipped
| seconds caused by leap seconds....
|
| For DST shifts and leap second things, aren't certain time
| strings just as ambiguous with a location-based time zone as
| they are with an offset?
| BoppreH wrote:
| > For DST shifts and leap second things, aren't certain time
| strings just as ambiguous with a location-based time zone as
| they are with an offset?
|
| Good point. I'd argue that location-based time zones make the
| uncertainty more explicit, but they don't remove the
| ambiguity.
|
| > epoch time is absolute
|
| That's a consistent approach, but is it _correct_?
|
| Let's say I'm today in America/New_York and I schedule a
| local meeting for March 15th at 13:00 (the day after Daylight
| Savings Time is scheduled to start). The string
| 2021-03-15T13:00-04:00, or its equivalent epoch time, is
| saved in your system.
|
| The government then decides to postpone DST by a couple of
| days.
|
| Your saved epoch time is now equivalent to March 15th at
| 14:00 in America/New_York. If you display it back to me like
| that, I'll complain your system corrupted my input.
|
| This can even happen to timestamps in the (recent) past,
| since abrupt changes can take days to propagate to user's TZ
| databases and lead to retroactive changes.
|
| If my meeting was stored in your system as "2021-03-15 13:00
| [America/New_York]" instead, there would be no problem. The
| same approach works with the virtual "local" timezone, used
| for alarm clocks, birthdays, new year celebrations, etc,
| which cannot be converted to epoch time.
|
| I don't know if this is the best solution, as I've never
| deployed it at scale. But it sure sounds more logical to me.
| kalleboo wrote:
| The tz database in itself is a massive project, that only
| somewhat recently (2011) started being backed by an
| organization (ICANN, which is not completely uncontroversial),
| and when ISO 8601 was created, it was still in its infancy.
| Additionally creating a timezone database from scratch was
| probably outside the scope of ISO 8601.
| sirn wrote:
| I think because it would defeat the portability of a timestamp
| because Asia/Tokyo isn't constant and you cannot lookup the
| offset without relying on external database that takes in
| ("2021-02-26 18:38:00", "Asia/Tokyo") as a parameter. Offset in
| zoneinfo changes depending on day of a year, and sometimes even
| hour of a day, and the database of timezone is constantly
| updated (latest zoneinfo is version 2021a).
|
| So while having 2021-02-26 18:38:00 Asia/Tokyo as a timestamp
| would more accurately represent the time, it would create
| another set of issues, namely requiring a database to look it
| up, and requiring to keep those database in sync in all systems
| in the world. Having both may be redundant because in that case
| you can't still trust the offset.
|
| There are alternative systems such as TAI64[1] based on TAI[2]
| that are meant to accurately represent the moment in time
| without being subjected to leap second (only account them on
| conversion to UTC). The main issue is TAI64 is not really human
| readable (e.g. @4000000037c219bf2ef02e94) and would still
| require database of leap seconds to accurately convert back to
| UTC.
|
| [1]: http://cr.yp.to/libtai/tai64.html
|
| [2]: https://en.m.wikipedia.org/wiki/International_Atomic_Time
| BoppreH wrote:
| I knew about TAI but TAI64 is new to me, thanks.
|
| About the TZ database, don't all date lookups require
| accessing it? If I schedule a meeting in Asia/Tokyo now, and
| the database tells me it's +09:00, I still have to remember
| it's Asia/Tokyo because the offset may change 5 minutes
| before the meeting.
|
| Analyzing the timestamp requires a TZ database, but that's
| calendars for you; the encoding is not going to change this.
| We don't actually know when the meeting will take place until
| it does.
|
| I'm still struggling to come up with a situation where
| including only the offset is the correct approach, which
| makes ISO 8601's decision puzzling.
| parhamn wrote:
| Most of the time you'd just need their current timezone
| offset (not location) to convert the stored offset into,
| no?
| BoppreH wrote:
| The stored offset was just my best guess for what Tokyo's
| offset will be at that date, according to my current TZ
| database.
|
| If the database changes, I have to go back and edit my
| timestamps (!), but I dont know which ones to edit
| because I didn't keep track of (1) which ones are +09:00
| because of Tokyo, as opposed to Seoul, and (2) which ones
| were created with the old database.
| sirn wrote:
| I think the main usage of ISO 8601 was to represent a point
| in time in UTC for exchange, not a local time plus
| timezone. When a date such as 2021-02-26 18:38:00+0900 is
| provided, it did not meant 2021-02-26 18:38:00 in
| Asia/Tokyo, but meant 2021-02-26 09:38:00 in UTC. e.g.,
| 09:38:00Z and 18:38:00+0900 and 16:38:00+0700 were supposed
| to be equivalent.
|
| In this case, timezone is external to this format and the
| timestamp can be calculate back to UTC without relying on
| zoneinfo (which is very useful for exchange). Any further
| conversation would be external to this format. e.g., in
| case of calendar, it's probably more useful to have
| datetime in local timezone rather than of the other party's
| timezone so the tuple would be (utc_time, local_tz) rather
| than (other_localtime, other_tz, local_tz).
| LordHeini wrote:
| I would absolutely not use this for IT purposes if I could avoid
| it.
|
| The simple reason is that I have been bitten by time zone
| shenanigans way too often.
|
| The same stands for databases always use timestamptz and not just
| timestamp.
|
| Every frontend framework has functionality to properly and
| reliably format dates for a given locale.
|
| As for filenames. It contains a space which is a pita for command
| line use.
| Grayskull wrote:
| Date and time are separated by "T" and timezone is specifiable
| but optional.
|
| From wikipedia: "If a time zone designator is required, it
| follows the combined date and time. For example,
| "2007-04-05T14:30Z" or "2007-04-05T12:30-02:00"."
| trinix912 wrote:
| > As for filenames. It contains a space which is a pita for
| command line use.
|
| The biggest problem I see is the time notation part using
| colons. Windows still doesn't allow using them in filenames in
| most places.
| rob74 wrote:
| This article is primarily about the _date format_ , and that
| doesn't have anything to do with the timezone, so it's a bit
| unfair to hold time zone issues against it. Some issues are
| also self-made because people (including people who write
| libraries, frameworks etc.) choose to store a date (e.g.
| somebody's birthday) as a datetime...
| globular-toast wrote:
| The US format is indeed awful but so is the European one really.
| ISO-8601 is the only one that makes sense, although the concept
| of months isn't really useful at all.
|
| But it's not always unambiguous. ISO-8601 supports local time.
| It's only an unambiguous timestamp of the time zone is included.
| young_unixer wrote:
| > although the concept of months isn't really useful at all.
|
| Made me chuckle, but I agree.
| trinix912 wrote:
| > The US format is indeed awful but so is the European one
| really
|
| There are many different European formats, some countries even
| use (a slightly modified version of) ISO-8601, ex. in the
| Nordics.
| lurkmurk wrote:
| "I can't remember the date to fill out this form. Can you help
| me, but give me the least informative part first?"
| lowbloodsugar wrote:
| What about the Y10k bugs?
| gorgoiler wrote:
| At best this is incomplete.
|
| Most humans talk about (month, date) tuples. US dates are big
| endian and written mm/dd. 12/25, 10/1, 2/28. They are elegant and
| compact and visually sort in the correct way eleven times out of
| twelve ( _11 /12_.)
|
| Short UK dates are spoken as "Jan 9th" "8th of March" and written
| as such, or sometimes "Feb 9". I find them very less pleasing.
|
| Longer UK dates in Guardian format are prettier: 3 Jan 2022.
|
| US dates inevitably have to be unambiguous about years. This is
| indeed unwieldy because a slashed triple -- 3/4/22 -- is used in
| the UK too. (The slashed pair is uncommon so it's clear that 3/4
| is an American date.)
|
| Anything technical should indeed use ISO, but if you have an
| audience in a single locale it's important to know your audience
| and localize (localise) accordingly.
| fredzel wrote:
| I'd guess most people, at least in Europe, learn British
| English, so US format of MM/DD is not really intuitive.
| [deleted]
| bambax wrote:
| I got into the habit of writing dates in this way perhaps 20
| years ago, in all my writings. People are sometimes surprised at
| first but the beauty of this is that they immediately get it.
| It's self-explanatory, obvious, in a way that no other format is.
| FooBarWidget wrote:
| Coming from China, western date and time formats puzzle me. In
| China we use the ISO 8601 order for dates. Because of this, and
| also for all the reasons stated in the article, I use the ISO
| 8601 format in all my software. As a user, it really bugs me when
| an app uses either the European or the US format, but doesn't
| tell me which one it is.
| alkonaut wrote:
| I wouldn't call ddmmyy "European". Many countries use yymmdd
| (nordics, for example) which is the iso order. And the order in
| which alphabetical or numerical sorting works out of the box.
|
| Other than inertia/tradition there is really no excuse for
| shuffling around a date in any other way.
| jbj wrote:
| my birthday is at the end of the month, during a processing of a
| document for my US visa 10+ years ago, I was dealing with 2
| different sites, one accomodating my local date formatting, and
| one fixed for the US standard. I was puzzled that I had been made
| 2 years younger when verifying my data, turned out my birth date
| of month was now month number 24+ of the year, pushing my birth
| ahead, and my birtb month had become my birth date of month.
| gnulinux wrote:
| I prepend my filenames with soemthing like `YYYY-MM-
| DD_HH:MM:SS.sss` or if second is enough `YYYY-MM-DD_HH:MM:SS`.
| The `T` there makes it hard to read for humans imho.
___________________________________________________________________
(page generated 2021-02-26 23:02 UTC)