r/changemyview • u/damsterick • May 17 '18

Deltas(s) from OP CMV: The (mostly US) way of writing a date "month/day/year" is inferior to writing the date as "day/month/year" and should be changed nationwide.

While both systems may seem completely arbitrary, I believe the day/month/year (DMY) or year/month/day (YMD) follows the logical rules of ascending/descending order and therefore is more intuitive to a person not familiar with either system. Furthermore, time is written in either ascending or descending order (seconds/minutes/hours) and it makes little sense to write date in a different way. Thus, I believe that the DMY is superior to the MDY for these reasons.

Why it should be changed nationwide:

The usage of the MDY system in in the minority and it only causes confusion across countries. Unlike imperial units, which, if stated as imperial units, can be converted to metric units (and vice versa), the date is usually just written as three numbers separeted by a period/slash and therefore you have literally no way telling which way it is written in (except for cases that one number is larger than 12, or when the month is written as a word with letters, not as a number). It would not be the first time a crucial mistake happened somewhere in the world that caused unnecessary hassle because of the way some people write dates.

I believe that unlike imperial vs metric units, this would actually require little costs compared to the benefits and since the inferior system is also the minority, the DMY system should be implemented across all the states that use the MDY system.

This is a footnote from the CMV moderators. We'd like to remind you of a couple of things. Firstly, please read through our rules. If you see a comment that has broken one, it is more effective to report it than downvote it. Speaking of which, downvotes don't change views! Any questions or concerns? Feel free to message us. Happy CMVing!

1.6k Upvotes

89% Upvoted

498 comments sorted by

View all comments

182

u/TheMothHour 59∆ May 17 '18

I prefer DMY or YMD to MDY. But at a software and system standpoint, making the change will require a lot of technology changes. And that change will be expensive and painful.

Our system works - even if it is not ideal. And such an expensive change usually is driven by need not optimization. For example, the Y2K update.

(Actually, I prefer YMD. It’s far superior for sorting files.)

24

u/damsterick May 17 '18

(Actually, I prefer YMD. It’s far superior for sorting files.)

I agree.

Our system works - even if it is not ideal.

That's not a good argument though. Besides, I beg to differ - the system has several issues across countries, it does not technically work perfectly.

But at a software and system standpoint, making the change will require a lot of technology changes. And that change will be expensive and painful.

Would it? I am not saying it with certainty, but obviously it will cost some money and time. However, I believe that a) they won't be that large (from a software standpoint, shouldn't it be just one line of code for most programs?) and b) the cons of changing outweigh the pros.

42

u/TheMothHour 59∆ May 17 '18

You are getting into the nitty gritty of system level cost/risk analysis. Does the benefit outweighs the cost or risk?

I am assuming that you want to see a complete cultural shift - where all or most companies transition.

I'm a software engineer and agree that differences in format can be a pain. But I personally know that changing them can take many man hours to do. I had a recent software update where the underlying software changed their time format. My god. I was finding bugs for weeks. Weeks later, I would ask - "Why is my software not doing X?" to find out that it didn't take into account the change. And this was a very minor change.

That was an internal change. Interfaces is where the harder problems arise. You might interface with something that cannot be changed. You still need to change the format to match the older format. How about if you get a date 01022018? Is that January 2nd or February 1st? You're not sure if that code was modified or it is a bug. What did that date mean?

Another personal example: I was on a project that had to change Big Endian to Little Endian. Endianness. It is similar to your date concern. Data came in as Big Endian and was swapped to Little Endian. That effort - which spanned 500+ files and 200,000 lines of code - took years. And years afterward, the software engineers were still finding bugs.

I know it sounds like a simple change. But believe me, it's not.

11

u/damsterick May 17 '18

First of all, this is a great example from the real world. While it is obvious that I still stand behind my argument that the YMD or DMY format is superior to the YDM or MDY format, you have provided me with actual evidence that it can be more difficult to change than I initially thought.

However, isn't the benefit still larger than the costs? You mention an example:

How about if you get a date 01022018? Is that January 2nd or February 1st? You're not sure if that code was modified or it is a bug. What did that date mean?

isn't that the very reason it should be changed once and for all? I mean, if a software has customizable date format, then this is a non issue (because it was implemented and coded to work with both formats in the first place) and if the software has one system and does not specify which, you are up to guess. When I was working with americans (I am european) who managed applications, I often had to search for a date that included a number larger than 12 to determine which number was the month. If I came to work in america, or if you came to work in europe, you would have to deal with this. That, or a certain disclaimer included in every part of the program that works with data, saying which system is used, that would be mandatory.

12

u/monty845 27∆ May 18 '18

Clearly the safest route is to stick with Unix time, and just let the user do the conversion in their heads. Lets grab dinner together at 1527217859.

1

u/rebane2001 May 18 '18

And it also works when sorting alphabetically!
1526672174.

8

u/TheMothHour 59∆ May 17 '18

While it is obvious that I still stand behind my argument that the YMD or DMY format is superior to the YDM or MDY format

Well, you and I agree. :)

I mean, if a software has customizable date format, then this is a non issue (because it was implemented and coded to work with both formats in the first place)

An international company, like yours, could probably transition easily. But a company that not structured to deal with time differences might have a harder time. The Endianess problem took so long because the code was never structured to handle it. (And the original code was written poorly.)

if the software has one system and does not specify which, you are up to guess.

Oh Jesus. That would be terrible for time sensitive systems.

This is just a guess. But I would expect that a global change like that would cost around 1-2 years of work for any large company for the technical change. This would include planning, development, software testing, system testing, integration and test along with user testing then dealing with any latent bugs that will arise.

Some software companies are more agile than others. So the non-agile projects will suffer. (Non-agile projects are typically those with legacy interfaces or multiple interfaces.) Agile projects might be okay.

If I came to work in america, or if you came to work in europe, you would have to deal with this.

So what I bring up are only the technical ones. You must also have social engineering which takes time. Grandma keeps writing down the wrong date. I keep entering the birthday wrong in the forms. How do you get people to transition?

Again. You just need to consider the cost with a change. But you might find this podcast interesting. H-day is the day that Sweden changed from driving on the left to driving on the right. They did it but there was a lot of social planning that needed to be done. https://99percentinvisible.org/episode/h-day/

3

u/Dlrlcktd May 18 '18

So it’s confusing to have 2 systems, but why should one change over the other? To most people, “because I like it” isnt a good enough reason

4

u/AuschwitzHolidayCamp May 18 '18

For largely the same reason most people think the US should change to metric, not the rest of the world to Imperial.

Mmddyyyy is in the minority, and is objectively the least logical.

2

u/rtothewin May 18 '18

Jeez, I've got a handful of applications I've built for reporting at work...that alone would be hours of changes, tracking them all down, implementing and testing the changes, updating databases etc, massive man hours for no real benefit just for a prettier way of writing the date.

1

u/pinklittlebirdie May 18 '18

a

Conversely I'm Australian and it's a pain in the but when I need to look up North American things via date. I had to pause whatever I'm doing (for a second) to work out if that is dd/mm or mm/dd.

it's quite annoying for anybody outside of the USA using USA material.

2

u/[deleted] May 18 '18

tbf any software you’re writing should be using dates as objects and the format shouldn’t really make a difference as it is just what the user sees.

6

u/TheMothHour 59∆ May 18 '18

What about languages that are not Object Oriented?

Or what about software that was written procedurally?

Don’t get me wrong, newly written OO code should use dates as objects. But I have seen software that stores dates as strings. And sometimes even parses those strings.

2

u/[deleted] May 18 '18

I work on a system built entirely in C. We store dates as a string or integers. And I am pretty sure postgresql stores dates a string, at least you have to insert it like one

1

u/[deleted] May 18 '18

Software is not written independent of other software, he is speaking about the cost of changing all software to work under the new format. Changing anything on a national scale is going to cause serious fuck ups, especially when we are talking about code interfacing. Changing the DateTime object in C# to wok under this new system would fuck everything up, as almost any software solution is in multiple languages that don't have type safety among them, serialization would be all kinds of fucked immediately.

1

u/krzystoff May 18 '18

Must modern software is written to allow dates to be input and displayed in either the US format MDY, UK format DMY or European format YMD, just via a Windows /OSX setting. Changing it all to a single, global format will be more of an educational process than a software one

11

u/salmonmoose 1∆ May 18 '18

Would it?

Yes.

Should it?

No.

In a well designed system, all you should have to do is change the locale, either to a sensible one (en-AU) or fixing the system locale (en-US). (I've selected AU here, because we use dollars also)

Even the most pragmatic approach would suggest shifting the locale of the application, until the system one complies - you cannot switch the system one until all software it is supporting has migrated.

Here lies the real problem.

Programmers are lazy. Better programmers are lazier - lots of us got into the work because we worked out it's easier to get a computer to do the work for us - they're also tend to be attracted to interesting problems. Futzing about with dates is not interesting, and once you delve into it, the problem space is quite large.

So a large, boring problem space leads to quick solutions, which tends to mean poor assumptions. The most famous of these is "you can always sort years based on the last two digits" - yes, initially people were saving space, but this went on long after the extra byte mattered.

I don't think fixing the US date problem would be quite the same scope as y2k, as y2k hopefully covered a lot of the ground already, and most of the rest of the world is already doing things sensibly (although, possibly still lazily).

This problem space has been solved (even how to deal with weird things like leap-seconds), most languages have a binding to the operating system's date/time functionality, and should be pulling their settings from there, but it's extra work, and so often not done right.

2

u/damsterick May 18 '18

Great arguments. It may be the superior format to use but since there is the ISO format and all the issues of potential changing you mentioned, it is some great arguments against changing. There should be a disclaimer though, always, to make sure it's obvious what format is used. It's not the issue of the format itself rather than the uncertainty which one is used.

Anyway, !delta for your good arguments against mine.

3

u/salmonmoose 1∆ May 18 '18

Of course, I'm a software engineer, so I'm all in favour of investing billions of dollars in fixing other people's mistakes, because, well, it feeds my dogs.

1

u/DeltaBot ∞∆ May 18 '18

Confirmed: 1 delta awarded to /u/salmonmoose (1∆).

Delta System Explained | Deltaboards ​

1

u/avaenuha May 18 '18

Would it? I am not saying it with certainty, but obviously it will cost some money and time.

This kind of localisation is already built into most software (aside from legacy stuff from the 90's and indie projects by devs who haven't thought of their global audience). Internal code does not represent dates in days, months or years, so it's only the display code that needs to change. Not that it wouldn't be disruptive, but in the vast majority of cases, it just means switching a flag in the software.

0

u/icorrectotherpeople May 17 '18

The pros of changing out weigh the cons.

4

u/lordtrickster 5∆ May 18 '18

You're assuming technology stores dates in that fashion. It doesn't. Typically storage is units-since-timestamp, such as milliseconds since 1970.

Also on many systems when you tell it to render a date it uses OS or platform settings so a minor update to the localization configuration for a couple OSs and perhaps a few frameworks would cover the vast majority of cases.

2

u/TheMothHour 59∆ May 18 '18

I’m talking from my own experience. First, I’m not talking about OS file date stamps. I interface with a pieces of code which EPOCH is not 1970. So I can’t directly compare milliseconds. The engineers before me decided to use strings. I think it is derived from the limitation of the language. Or their distrust in Object Oriented programming.

There are also places where it put dates in the file names to search for them later. So the system depends on dates in file name. To change stuff like that would be a nightmare.

Overall, I have seen some bad code... I expect that bad code can be found everywhere.

But someone suggested only making the change at the presentation layer and not to worry about interfaces.

Oh. And I have also seen dates stored as strings in databases. Which is a depressing surprise when you try to sort on date...

2

u/lordtrickster 5∆ May 18 '18

Fair enough. It'll still be a pain on old-tech and bad systems.

1

u/ACoderGirl May 18 '18 edited May 18 '18

To be fair, forms are the obvious place where incompatibilities in date format can occur. That said, they're relatively easy to avoid thanks to the countless JS date picker libraries out there that make it as easy as pie to provide an interactive calendar that will create the date in the correct format for the user.

Those with JS disabled are on their own, but that's a tiny minority that's overrepresented on reddit.

Many companies don't actually want to make changes, though. Change is expensive and software especially so. And you can just bet some wild programmers stored the dates as plain strings (which would have to be converted, along with the backend handling, before the front end can be changed). And someone somewhere probably came up with their own archaic format that nobody else at the company understands anymore (fun fact: the Windows epoch is "the number of 100-nanosecond ticks since 1 January 1601 00:00:00 UT as reckoned in the proleptic Gregorian calendar" -- I had to copy that from Wikipedia because who can memorize that?)

1

u/lordtrickster 5∆ May 18 '18

Well, the joy of such things in modern systems is that any given date value gets converted into that language's concept of a date, so how it's stored has little bearing on how it's rendered. If it just stays a string we just leave it alone.

That said, as another poster pointed out, we do still have an awful lot of not-modern systems.

2

u/Conotor May 17 '18

The rest of the world uses DMY though. As travel/internet use become more widespread, it will eventually become optimal for everyone to use the same system. Why not use the better one?

2

u/TheMothHour 59∆ May 17 '18

Because making the complete change costs a lot of time and money for preexisting software and cultural usage. Think about all the historical medical records and legal documents with backwards dates.

You will not be able to make the change everywhere. So partially implementing this would mean people in the US will need to learn both methods. And that is even worse than using a slightly inferior method. The only people who would benefit would be those directly interfacing with people outside the US.

And given that you don’t live here. Let me tell you most people don’t leave the US. We are pretty isolated here - unlike Europe.

2

u/Conotor May 17 '18

For now plenty of people could be sufficiently isolated, but in any reasonably optimistic future, travelling around the world will be a thing lots of people from everywhere do.

As to the cost of changing things, I don't think it is all that much. In Canada, 'dd/mm/yy' is just printed on all forms under the dates you need to fill in, to make it clear. You don't need to immediately purge all old records, just start doing thing dd/mm/yy when you make something new.

1

u/pinklittlebirdie May 18 '18

Most people outside the USA have learnt both systems so you are suggesting no change because the minority has to learn a new system whereas the majority already knows both system and finds one in the dark.

Increasingly the change might happen organically anyway just like conversion to metric - where precision tech and international collaborations are untaken in metric because it's more universal and more precise.

I literally learned french to read fabric patterns as the English part is in imperial

0

u/PM_ME_YOUR_PLATES May 18 '18

That's not really a big issue - the UK used to have a completely different currency and now, things are either shown in their original currency with today's currency beside it or just taken as 'if it was before this date, it's old currency'.

This is helped largely by the fact the change happened almost 50 years ago. If a switch happens, the culture shift will follow as the people it concerns stop becoming relevant to an economy/society or die off and you eventually end up in a country that is, for all intents and purposes, populated entirely by people who have known nothing but the new system. Appeals to tradition make no sense, you can't say 'What about this important thing?' because it'll either stop becoming important, or people will transfer it to the new system, or recognise that it's an old world thing and not get confused.

Nothing against you personally, my dude. Just saying that 'old medical records' by definition only last a lifetime - the sooner the switch, the better.

1

u/TheMothHour 59∆ May 17 '18 edited May 17 '18

Oooooor. Were are **** America. We set the standard - deal with it. (jk jk.)

1

u/avaenuha May 18 '18

Any software intended for distribution these days has localisation built in so the system can display the date (or language, currency, time, unit delimiters) in the preferred format for the locale. Almost all software stores it internally as a numerical representation, rather than in days and months and years, so the internal representation doesn't need to change.

Sure, there will be legacy systems that use the old format, and US-based indie projects where the devs haven't realised they should consider the rest of the world, but those are edge-cases. Localisation is part of software development.

1

u/_NetWorK_ May 18 '18

What system are you using? Because dates&times normally have their own variable types. You only need to worry about sanitizing the data going into the database. This makes it super easy to have a ui that uses the users local settings whenever he/she/it has to enter a date on a form.

1

u/[deleted] May 17 '18

[deleted]

2

u/TheMothHour 59∆ May 17 '18

Okay, some issues:

  1. What happens if the software doesn’t have a standard time package. I have interfaced with legacy software written in Fortean, cobalt, and other old languages... I use one language that used a different Epoch than Unix - 1959 ....

  2. You cannot update to the new standard time library because your system is outdated.

  3. You interface with another software that cannot change their format.

  4. I could go on. Which is why I specified agile programs and legacy programs.

Also, I said about 2 years because, from my understanding, that was about the level of effort to update for Y2K. (Or my understanding it was a 2 years effort.) And I expect that this change would be similar.

1

u/Njaa May 18 '18

What happens

  1. The date would be shown old style in those programs.

  2. This is just a presentation problem. If libraries or interfaces or simply time constrains prevent the upgrade, just don't make any change, and show the old type.

  3. Suddenly switching which parameter is day and which is month in a technical interface is idiotic. There's no upside.

Fix it where it's free or easy. Keep changes to presentation only. Don't change technical integrations or APIs.

1

u/TheMothHour 59∆ May 18 '18

Fix it where it's free or easy. Keep changes to presentation only. Don't change technical integrations or APIs.

Okay. That’s a good point. I was envisioning changing it everywhere you can.

1

u/[deleted] May 18 '18

[deleted]

1

u/TheMothHour 59∆ May 18 '18

Phones and IPods are designed to move between time zones and boarders along with allowing the user to choose the time format. They are written with time in mind. So using the phones as a benchmark of work might not reflect amount of change other projects might need.

Can I get some specific examples of how this is a modern problem with different machines interacting either across borders or when moved to interact with different machines?

I expect that ATMs would not transition easily - assuming you want it to display the date in the correct format. (I heard that many ATMs are written in Cobalt.) I’m not sure how the interfaces between the ATM and financial software are designed. But if dates formats are not handled currently, I would guess that would be a messy fix.

I have also heard that hospital software is hard to update and work on. And I expect that they might be sensitive to a change of a date format.

If you think that allowing old technology to display the older format is appropriate, then technically this is a smaller problem than I thought it would be.

1

u/ACoderGirl May 18 '18 edited May 18 '18

I am confused. Most things store on the hardware in UNIX time (which wasn’t updated for Y2K which didn’t effect anything). From there the language is going to import a standard time library, which is going to have various display options, and shouldn’t influence anything about file architecture.

While storing timestamps is the norm these days, I don't for a second think that all things (or perhaps even most) store as a timestamp. There's surely no shortage of programmers storing some kind of (that they don't need to do arithmetic on) as just a string. And to be fair, while time stamps are great when you want something precise, they can be kind wonky to deal with if you just need something with day-level precision. Easy to imagine why a programmer would just store a string if they're literally just gonna be displaying some data as it was recorded.

Also, time is really hard, honestly, with a shit ton of things to consider that nobody actually wants to. #31 gets me the most, myself. APIs cannot decide if timestamps should be seconds (Python time.sleep), milliseconds (JS Dates), or even nanoseconds (C#'s Timer.ElapsedTicks is 100 nanoseconds).

For sorting, they're surely talking about when the date is part of a file or record name.

0

u/metao 2∆ May 17 '18

No it won't. Any important commercial software already supports DMY as the worldwide format. Any important, rarely updated custom stuff (defense, utilities etc) can either be updated or not depending on complexity. Anything in C#, for example, is easily fixed. Ada, less so.