Should the date always be formatted in yyyy/mm/dd?

Discussion in 'General Philosophy' started by BdS, Mar 4, 2014.

  1. BdS Registered Senior Member

    Should the date always be formatted in yyyy/mm/dd hh:mm:ss? Should it even be optional to format it in a different way?

    If we consider the time portion hh:mm:ss we always have hh:mm:ss in the correct logical grouping. hh:mm:ss goes from the highest units to the lowest from left to right. And people logically use this logic in the time portion of the date. If I ask you the time and you say its 10:15, I dont confuse where the 10 and 15 belong, you said 10:15 and I didn’t stop and go did he mean 15h:10m or 10h:15m. hh>mm>ss the logical sequencing for it is hh:mm:ss, its the correct way of formatting the time from highest units first to lowest last.

    When it comes to the date people dont follow the same logic eg.
    I see a date 11/10/08. Now I’m left assuming the format, because people always mix up the units. Now thinking, did it mean yy/mm/dd, mm/dd/yy or dd/mm/yy. Like on this website I see the date goes mm/dd/yy. If we use the same kind of logic we use with time then the only way to format the date is from the highest units to the lowest yyyy>mm>dd. Any date that does not follow that logical ordering, shouldn’t even be considered a valid date.
    When the whole format of the date is done from highest to lowest units then the date time can even be used as a increasing series of whole numbers, the hh unit must be in 24h format for us not to get any duplicate whole numbers and any unit that is < 10 must always have 0 before the number 01 02 03 04 05 06 07 08 09.

    $lngDate1 = 20140105140234 (the long is in the format yyyymmddHHMMss)
    $lngDate2 = 20140106140234 (the long is in the format yyyymmddHHMMss)

    If I want to find any records that contains the lngDate value
    Select all records from archive where Records.StoredLongDateValue >= $lngDate1 and <= $lngDate2
  2. Google AdSense Guest Advertisement

    to hide all adverts.
  3. Fraggle Rocker Staff Member

    If it's actually written with the slashes (in any established manner: 3/7/14, 03/07/2014, etc.) then it is presumed to follow the 20th-century American paradigm of month/day/year. Of course this is utterly illogical, that's what makes it so American; we could at least have put the low-order digits first instead of in the bloody middle! And other countries arrange the numbers differently, so that might mean July 3rd instead of March 7th to someone in Kazakhstan, or July 14th, 2003, in Paraguay.

    But if it's written without the slashes, it's usually assumed to be computer-readable. So the high-order digits do indeed come first: 20140307 = year 2014, month 03, day 07. And of course the zeros are never suppressed.
  4. Google AdSense Guest Advertisement

    to hide all adverts.
  5. BdS Registered Senior Member

    It should not be optional, its just simple logic that the only correct way is highest units to lowest. Common sense is not that common... It should be a international standard and would eradicate all confusion.

    Yes computers will read the integer or long data type as a date if you tell the computer to convert the number to a date.

    dim lngdate as long = 20140309094235
    dim date1 as date

    date1 = convert_date(format(lngdate, "yyyy/mm/dd HH:MM:ss"))
    date1 is now = to a computer readable date data type 2014/03/09 09:42:35

    From here you can shuffle the units, which IMHO should not be allowed.

    date1 = format(date1, "mm/dd/yyyy ss:MM:HH")
    date1 is now = 03/09/2014 35:42:09

    This is a VS IDE example
    Format function for VS-Visual Basic
    Type conversion function for VS-Visual Basic
  6. Google AdSense Guest Advertisement

    to hide all adverts.
  7. Olinguito Registered Member

    It’s not only logical but highly practical. The yyyy_mm_dd_hh_mm_ss format is the only one which with the chronological ordering (oldest to most recent) coincides with alphabetical ordering.
  8. Fraggle Rocker Staff Member

    How often do you find logic to be a major factor in the ways humans devise for communication?
  9. James R Just this guy, you know? Staff Member

    It's America's fault again.

    In Australia, we write dates as day/month/year. (This post was on 26/3/14).

    It annoys me that my sciforums preferences don't allow me to change the dates to dd/mm/yy rather than the mm/dd/yy format.

    As a defensible system, it seems to me that yy/mm/dd (or yyyy/mm/dd) makes the most sense, but cultural inertia will ensure that nothing changes any time soon.

    But, if you're going to insist on doing things the "wrong" way, then I do think that dd/mm/yy is more defensible than mm/dd/yy. At least the former goes logically from smaller time intervals to larger ones; I can't see how the latter makes any sense at all.

    Then again, what do you people say when somebody asks you the date?

    For me, today is "the 26th of March, 2014". Do Americans say "Today is March 26, 2014"?

    And when you write the date out in long form, say on a letter, what do you write? I write "26 March, 2014". Do you write "March 26, 2014"?
  10. cluelusshusbund + Public Dilemma + Valued Senior Member

    mm/dd/yyyy is the most orderly... from smallest posible range of numbers to the largest posible range of numbers... ie... mounth= 1 thru 12... date= 1 thru 31... an year= thousands of posible numbers.!!!
  11. Olinguito Registered Member

    In Britain we use day/month/year format as well, but personally I prefer the year/month/day format for the reason I mentioned in post #4 above.

    Usually there is no confusion over whether day/month or month/day format is used – for example, if someone writes 3/28/2014, we know that they mean “March the 28th”, since there is no month 28. Similarly when they write 4/4/2014, there is no confusion at all as to what date that is.

    Question: If Americans like to put the month before the day, why do they say “fourth of July” instead of “July the fourth”?

    Please Register or Log in to view the hidden image!

  12. gmilam Valued Senior Member

    Yes, we do... (At least I do.) Although I prefer yyyy/mm/dd.

    Then again, I'm a programmer by trade and prefer something a computer can sort by.
  13. Gremmie "Happiness is a warm gun" Valued Senior Member

    I was military, then got into law enforcement... So for me, it's always been dd/mm/yyyy... I could never see it any other way. Yeah, can't teach an old dog new tricks. Woof.

    I.E. today is 28 April 2014...It actually bothers me to see it any other way. Yes, I'm set in my ways.
  14. Asguard Kiss my dark side Valued Senior Member

    Computers can read dd\mm\yy (or yyyy). You just have to program it that way and personally considering programmer laziness was threatening to bring down planes and the whole GPS network in 2000 because programmers couldn't see a world surviving after the year 2000, and the expense that the rest of us had to pay to FIX this laziness, well basically do your job. Computers exist to serve us not the other way around, if the database requires the date be flipped in the programming then write the code to ensure that the input and output are as those of us who use the system want and the back room processing can use the data as it needs to. Stop trying to make society bend around the processor rather than the processor bend around society
  15. gmilam Valued Senior Member

    The software I work with does indeed have a date format setting that we use to translate the format while transferring to and from the user and the database. However, we store it in *ISO format (YYYYMMDD).
  16. BdS Registered Senior Member

    In the time portion always, in the date portion very seldom.

    Please Register or Log in to view the hidden image!

    It should be the goal of science to make logic (when achieved) the correct and only factor we should use. Especially since we started communicating internationally, we should all use a internationally accepted protocol for communication. Specially for things like the date and time that are a universal consistent entity. To be totally through it would require the time zone too 2014/03/31 23:03:45 UTC+2

    2014, March 26 would seem to be the correct way. Highest unit denominations to lowest.

    Please Register or Log in to view the hidden image!


Share This Page