The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

12-hour clock confusion

We are developing a portable equipment that will be able to switch between 24 and 12-hour clock. Since 24-hour clock is standard here in Europe, I have no experience with the AM/PM clock.

I have found here: http://ww2010.atmos.uiuc.edu/(Gh)/guides/maps/utc/utc24.rxml that 00:10 (10 minutes past midnight) is converted to 12:10am and not 00:10am. Is this really common, meaning that 00:10am is a nonsense?

Thanks for clarification,
Petr
Petr Veit
Wednesday, April 02, 2008
 
 
Yes, that is correct.
JB
Wednesday, April 02, 2008
 
 
Yes. With a 12h clock, it's 12:10 AM (not 00:10).
somebody else
Wednesday, April 02, 2008
 
 
"Is this really common, meaning that 00:10am is a nonsense?"

If you're going to display the time to people here in the US, then yes, don't do that.

FYI, "is a nonsense" isn't the correct term. You would either say "is invalid", which is almost certainly what you meant, or "is nonsense", which means that it's stupid.

No offense meant, you certainly speak English better than I speak your language (:=)
Steve Hirsch Send private email
Wednesday, April 02, 2008
 
 
This is a good example of some of the subtle issues with building software that really works (and makes sense!) everywhere in the world. 

Proper timezone handling turned out to be one of more aggravating issues to get right with our application - everything from how you let customers pick their timezone to proper handling of daylight savings time, dealing with POSIX's annoying interpretation of GMT+n, etc.  With the internet being as pervasive as it is now, it's difficult to narrow the problem down.  We were about to ignore those funky timezones that are't a full hour off of UTC, only to have our third customer that signed up come from UTC+5:30...
Jason Abate Send private email
Wednesday, April 02, 2008
 
 
The idea here is that you've got an analog clock dial with 12 at the top, six on the bottom, and so on.  At ten minutes past midnight, the hour hand points just to the right of the 12, and the minute hand points to the 2, and it's read as 12:10 am because the 12 stubbornly refuses to morph into a zero every night at midnight, only to morph back into a 12 at 1:00 am.
D. Lambert Send private email
Wednesday, April 02, 2008
 
 
00:00 - 11:59 = 12:00am - 11:59am
12:00 - 23:59 = 12:00pm - 11:59pm
Ted
Wednesday, April 02, 2008
 
 
But although 12:01 am is one minute past midnight in the early morning and 12:01pm is in the afternoon - 12:00am is midday and 12:00pm is midnight!
Martin Send private email
Wednesday, April 02, 2008
 
 
Martin's post illustrates a known problem of 12 hour time, in that nobody agrees on the AM or PM-ness of noon and midnight.  See this article:

http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight

To get around this, the safest option is to store time as GMT, and then use your platform's localization settings to convert to whatever crazy format your user prefers.
Kevin
Wednesday, April 02, 2008
 
 
Martin, there may be a technical standard where that's true, and I can understand why it would be true, but I think you'll only confuse people by implementing it that way.  Most people in the U.S., at least, will expect that 12pm is noon, and 12am is midnight.
Kyralessa Send private email
Wednesday, April 02, 2008
 
 
Re: 12 am/pm == noon/midnight (or vice-versa)

I'm a U.S. citizen, born and bred. I allegedly learned to tell time in the U.S. public (that's government run) school system, and I STILL can't keep straight whether 12 am is noon or midnight. Just to be safe I try to always refer to the times exactly at 12:00 am and pm as "12:00 noon" and "12:00 midnight" just to avoid the issue (or I just use military time, in which there is no confusion).

I second the suggestion that you rely on the C standard library time formatting functions, which should do a reasonable job of converting nice, sane GMT 24-hour time into something that makes sense to your benighted customers (such as myself and my countryfolk). Lots of work has gone into the C standard library and there's no reason for you to suffer through this nonesense if you don't need to (of course, if you are not writing your software in C or C++, and your language and platform of choice don't provide a suitable API for localized formatting of time values, then you have my condolences).
Jeffrey Dutky Send private email
Thursday, April 03, 2008
 
 
Thank you guys for all the comments and especially to Steve Hirsch for teaching me something new in English language. Yesterday I read an article in the newspapers that English is slowly mutating into something like "International English" as more and more people try to communicate in this language. That's why it's good to correct mistakes.

According to our portable device, forget about any API. It is running on ARM processor and it is coded in C, so we have to take care of everything.

So far, the international settings are following:

- Country selection: user can select his country and language + all formating parameters are set automatically.
- Language: set your language
- Date format
- Time format
- Daylight saving time

I hope this will be enough, since the equipment is used always locally (not moved during use).
Petr Veit
Thursday, April 03, 2008
 
 
We use international English in more than one way. For us as non-native speakers it is undoable to know the exact difference between British English and American English, so we have developed a number of best practices. These rules help us to standardise our language. That is very important for searching in specifications and documentation.

Similarly, for dates and times we only provide one unambiguous format (yyyy.mm.dd @ 23:59:59) that cannot be deviated from. I have been using these formats for approximately 20 years now and /never/ had complaints. I have had questions why I use the format (which is different from the Dutch locale), but I have never met someone who did get it. It has made our software development and testing a lot simpler and took away any risk of confusion of the user.

Similarly, when we use physical units, these are always SI-units. This may not always be acceptable for input and output as seen by the user, but internally there is no exception to this rule. It has saved our neck more than once.

http://www.hello.nl/articles/InternationalEnglish.html
Karel Thönissen Send private email
Thursday, April 03, 2008
 
 
Oops: who did NOT get it.
Karel Thönissen Send private email
Thursday, April 03, 2008
 
 
Anoher interesting international issue I recently ran into was the display of real numbers. In the US (and other places?) we use a period to denote the location of the decimal point, so pi is displayed as 3.14159. But in other locations a comma is used to denote the location of the decimal point, so pi is displayed as 3,14159.
Anominal
Thursday, April 03, 2008
 
 
Interesting, Karel. What type of users are you targeting with your product? Where are they located? The products that I work on are typically used by people with a low-level of education: typically 2 years of college or less. I am currently working on products that are geared for people who likely do not have a high-school education (to use the US nomenclature). As such, we have tried to present information in a format that is as familiar as possible for the user. I am interested in your experience with this.
Anominal
Thursday, April 03, 2008
 
 
>Anominal
One side effect of this is that CSV format in say Germany, is really Semicolon separated, but still called CSV in the menu!

ps. The worst is S.Africa, their maps have an interesting idea about which way N and E should go. Great if you are doing complex 3D mine planning software.
Martin Send private email
Thursday, April 03, 2008
 
 
"One side effect of this is that CSV format in say Germany, is really Semicolon separated, but still called CSV in the menu!"

This is exactly what we ran into! We dumped a bunch of raw data out to a comma-delimited text file in Germany and couldn't open it in Excel.
Anominal
Thursday, April 03, 2008
 
 
Anonimal,

I was writing another reply in this thread, but made a small mistake and lost the work. I do not have the time to rewrite it again, so briefly.

I propose three things actually:

1) make a strict separation between internal formats and representations and external formats and representations for the user
2) for the internal representation use very precise formats, representations and definitions that make sense
3) for your user: stay as close to the representations, definitions and formats from point 2 above as the intended target group can cope with.

ad 1). Never make the same mistake as Microsoft and others did with CSV. Persistent data, serialised data, programming code, spreadsheet formulas, etc. are from a technical domain and should never be localised.

http://discuss.joelonsoftware.com/default.asp?design.4.581096.7

ad 2). Use standards that really make sense:

- dates: yyyy.mm.dd with all leading zeros (not yyyy-mm-dd since that does not mix with program code)
- time of the day: hh:mm:ss with all leading zeros
- time: yyyy.mm.dd @ hh:mm:ss with all leading zeros
- SI-units, literally nothing else. Ask your local Nasa-representative for more information, keyword: 2 lost missions to Mars
- A4 as standard paper format
- period as decimal separator
- underscore as thousands separator
- strict distinction between base-10 prefixes and base-2 prefixes
- interpretation of 'billion' as used in every country in the world except 1 maybe 2.
- use a simple coherent spelling (particularly in Dutch, where the authorities have the brutality to change the spelling rules every 10, 15 years which breaks your ability to do full-text retrieval on your documentation)

ad 3). I use yyyy.mm.dd in everything I do, both in programming and writing on paper. Literally no complaint ever. The thing is, there is only one reasonable interpretation. In the Netherlands as in much of the rest of Europe, the standard is dd-mm-yy or dd-mm-yyyy, often with periods rather than hyphens. People will instantly see the difference. More and more people start using this once they have sorted their digital photos by date (-8.

One thing I really, really hate is this. The American notation of mm/dd/yy is a kludge already. Now there are graphic designers in the US who start using mm.dd.yy or mm.dd.yyyy, thus making the non-ambiguous European format ambiguous from now on.
Karel Thönissen Send private email
Thursday, April 03, 2008
 
 
Be careful when programming for daylight saving time, as the rules are subject to change on a whim:
http://en.wikipedia.org/wiki/Year_2007_problem

@Karel: "yyyy.mm.dd with all leading zeros (not yyyy-mm-dd since that does not mix with program code)"

What is the problem with using yyyy-mm-dd?  That is the ISO standard for dates, and I have used it for many years:
http://en.wikipedia.org/wiki/ISO_8601
Mark Ransom Send private email
Thursday, April 03, 2008
 
 
> FYI, "is a nonsense" isn't the correct term

Seemed entirely correct to me. This might be a pondial thing if it's not considered correct in American English: it's certainly fine in British English

http://www.google.com/search?hl=en&q=%22is+a+nonsense%22+site%3Abbc.co.uk
Larry Lard
Thursday, April 03, 2008
 
 
Mark,

2008-04-03 is 2008 minus 4 minus 3, thus equals 2001.

In the Carmen programming language that we developed, dates are primitive types that have their own literals.

For the same reason we can use these literals in marshalling without any ambiguity.
Karel Thönissen Send private email
Thursday, April 03, 2008
 
 
+1 to being careful about daylight saving time adjustements.

Another gotcha is the leap-second, added every so often when needed (the earth is gradually slowing down, so sideral time (where the sun will be at noon -- SHOULD be directly over Greenwich) slowly moves over time).

This means there may indeed be a time "24:00:00", which then 'rolls over' to 00:00:01.  Or 11:59:60 PM, which rolls over to 12:00:00 AM.  This can be a problem if you code assuming it NEVER happens.

And there is a "Day 366" every 4 years -- so don't assume the end of the year rolls over after day 365 every year.  My watch is dumb about this, and every leap year I have to set it back a day to cope.
AllanL5
Thursday, April 03, 2008
 
 
Oh, and I always thought "12:00 AM" was "Midnight" -- the day starts at 12:00:00 AM and moves forward.  That's always the moment of New Years, anyway.

So 11:59:59 AM is the last second of the "morning", after that it's 12:00:00 PM.
AllanL5
Thursday, April 03, 2008
 
 
Allan, good point about leap seconds.  This stuff sure does get complicated in a hurry, doesn't it?

Speaking of which, leap years are a little more complicated than just dividing by 4.  The proper formula for determining leap year is:

if((year%4==0 && year%100!=0) || year%400==0)
// leap year

Joel has a fascinating anecdote related to that:
http://www.joelonsoftware.com/items/2006/06/16.html

We really lucked out that 2000 was divisible by 400.  I wonder when they'll start talking about the year 2100 problem?

If you think of PM as meaning "after noon", then it makes sense that 12:01 after noon should be PM.  It also makes sense that 12:00 should have the same designation, or it would be terribly inconsistent.  I remember being confused about the noon/AM/PM thing as a child until I thought it through.

One last thing - make sure your test cases include those awkward times when daylight saving time is switching in or out.  Local time will be doubled up for an hour in the fall, and an hour will be missing in the spring.
Mark Ransom Send private email
Thursday, April 03, 2008
 
 
Here is a quote from the National Maritime Museum, Greenwich, England:

To avoid confusion, the correct designation for twelve o'clock is 12 noon or 12 midnight. Alternatively, the twenty-four-hour-clock system may be used. The abbreviation a.m. stands for ante-meridiem (before the Sun has crossed the line) and p.m. for post-meridiem (after the Sun has crossed the line). At 12 noon the Sun is at its highest point in the sky and directly over the meridian. It is therefore neither "ante-" nor "post-".
DaveW
Thursday, April 03, 2008
 
 
I have to deal with a wonderful date format, it's an integer representing whatever the user happened to feel like entering.  20080401 040108 010408 01042008 etc....
Martin Send private email
Thursday, April 03, 2008
 
 
In the U.S., nearly all digital clock displays have an AM/PM indicator.  Every one that I've seen displays PM for noon and AM for midnight.  If there was confusion in the past, I don't think it exists anymore.
Mark Ransom Send private email
Friday, April 04, 2008
 
 
Mark, in the context of a physical clock there isn't much scope for confusion.  When the time is actually 12:00, it's very unlikely that you will not know whether it's midnight or midday, unless you live in a deep cave completely cut off from the outside world.  :)

It's only when you're representing times other than the present that ambiguity can arise.
Iago
Saturday, April 05, 2008
 
 
Yes, exactly noon is 12:00m, it is neither am nor pm.

Midnight is 12:00am since it is _before_ noon.
Scott
Saturday, April 05, 2008
 
 
By the way, this talk about how europe is on 24 hr time is stupid. They have 12 hr watch faces just like everybody else in the world, and tea time is 4 o clock, not 1600.
Scott
Saturday, April 05, 2008
 
 
The clock face in Europe indeed has twelve hours. But no it is not that stupid.

In several European countries it is common to use the 24-clock in /speech/. In other countries, e.g. the Netherlands, one uses the 12-hour clock in speech, but the 24-hour clock in writing (the 12-hour clock in writing is extremely rare in the NL).
Karel Thönissen Send private email
Saturday, April 05, 2008
 
 
Thank you for the clarification.

In the US, the military uses 24 hr time and people with military experience tend to keep using it their whole lives in speech. "How bout we meet at twenty-hundred?" from an associate tells you that he has a military background.
Scott
Sunday, April 06, 2008
 
 
Karel: it's the same here in Czech republic. Wen talking, everybody uses 12-hour format. If there is any confusion, I will say "at five evening/morning". When writing, we normally use 24-hour format.
Petr Veit
Sunday, April 06, 2008
 
 
Interestingly, after reading this thread, a weekend ago my wife, kid, and I were walking in a big park and saw a police sign posted on some roads.  It read:

"NO PARKING BY POLICE ORDER
12:01 am - 12:01 pm"

So I guess whoever posted that sign also thinks the potential for confusion is real.

I'm inclined to agree with those who say "12 midnight - 12 noon" is more clear.
Kyralessa Send private email
Monday, April 14, 2008
 
 
"What is the problem with using yyyy-mm-dd?  That is the ISO standard for dates, and I have used it for many years"

We use dd.mm.yyyy or actually d.m.yyyy in Finland. I have used to it and it feels ok.

Instead yyyy-mm-dd feels like its just wrong or at least unnecessarily strange. I understand that if someone has learned to use that format, but I will never go to it. Of course if there is some system that forces me use that format, I have to use it, but I don't like it.

It would be better that the whole world went to a certain standard instead of that everyone is using what they have used to.

What comes to the am/pm, I think its easier to write 20:00 than 8:00 pm. I can still also write and say at eight in the evening. And I can still use 20:00 and say again at eight in the evening.
Silvercode
Wednesday, April 16, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz