Timestamp

[Camron W. Fox]

Paul L. Allen wrote:
> Greg Vickers writes:
> 
>> Paul L. Allen wrote:
> 
> 
>>> It's more complex than that.  Most of the US uses mm/dd/yyyy but the US
>>> military uses dd/mm/yyyy.
>>
>>
>> God, you're kidding??
> 
> 
> Nope.  While trying to find a reference to the US military usage (it's
> probably in MIL-STD-00001 or something like that) I found this: <URL:
> http://en.wikipedia.org/wiki/Calendar_date > which shows the situation
> is far worse than I thought.  US Federal government often uses dd/mm/yyyy
> (and, since the US Military is part of the Federal government you can
> deduce that they use it too).  Canada uses BOTH.  Most European countries
> use dd/mm/yyyy.  The UK started with dd/mm/yyyy, switched to mm/dd/yyyy
> for a while then reverted to dd/mm/yyyy around 1900.  Sweden uses
> dd/mm-yyyy and yyyy-mm-dd (the only European country in the list on that
> page to use yyyy-mm-dd).  And there are plenty of other oddities,
> especially the US military one near the end, where 5102 would be the
> 102nd day of 2005.
> 
Gents,

Actually, this is misleading. Currently, the U.S. Military either uses 
yy/mm/dd or Julian date, depending on the context (operations, 
reporting, etc.). This, however, doesn't make it any less confusing for 
"civilians".

Best Regards,
Camron

-- 
Camron W. Fox
Hilo Office
High Performance Computing Group
Fujitsu America, INC.
E-mail:		cwfox at us.fujitsu.com



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null