Re: Linux Date Command gives wrong year with +%g | Hacker News Reader

Re: Linux Date Command gives wrong year with +%g

lists.gnu.org

31 pointsbillpg13 comments

It's wrong in the sense that not the obvious result users expect. But it's 100% technically right.

It's always tough to deal with this kind of situation. Do you document it all over the place and hope users read it? Do you parse the command when it's first created and warn the user that %g is different than %Y? Do you just ignore the issue and deal with the small number of emails at the beginning of every year?

I think a combination of docs + automated checks is best depending on the circumstances.

Probably "wrong" here should be in scare quotes. It's not the wrong year; it does return the correct ISO year. It's just that ISO year is not what you want so you should be using %y rather than %g.

Check the actual link: that's exactly what the email linked to says. (And the title here is simply the title of the email.)

I'm assuming that (1) the poster is warning others about this or (2) he finds it amusing that the response to "The year is wrong" is (roughly) "No, that's how the standard defines year. The output is right relative to that standard. Dates and times suck." (the last sentence is implied) or (3) both.

And thusly the "problem" is not one of Linux but a funny characteristic of our universe.

Here is how strftime on OSX defines it:

     %G    is replaced by a year as a decimal number with century.  This
           year is the one that contains the greater part of the week
           (Monday as the first day of the week).

     %g    is replaced by the same year as in ``%G'', but as a decimal
           number without century (00-99).

Makes sense to me. People should read the man pages more often before they jump to conclusions.

Granted, that is more clear than man date on Linux (on OSX it doesn't define the format variables):

       %g     last two digits of year of ISO week number (see %G)

       %G     year of ISO week number (see %V); normally useful only with %V

       %V     ISO week number, with Monday as first day of week (01..53)

%g tells you the year (modulo the century) in which the current week's Monday took place

when would you actually want to use an ISO year though? just to claim ISO compliance?

Things get weird if you use weeks as a unit and then also display the year. For example, if you have an event that took place on 2010-01-01, then iso_week_of(2010-01-01) will return 53 and year_of(2010-01-01) will return 2010. So your wonderful app might display "Week 53, 2010", which makes it look like it's the end of 2010.

Can someone please explain what ISO years are and when the correct time to use them is?

They match up with ISO week numbers, where week 1 always starts on a Monday.

I regularly see ISO weeks used to mark manufacturing dates, where they often offer the right levels of precision, as many processes run on week-long cycles. Often in stampings the year will be replaced by a letter code with an epoch particular to the company.

http://en.wikipedia.org/wiki/ISO_week_date

The ISO week date system is a leap week calendar system that is part of the ISO 8601 date and time standard. The system is used (mainly) in government and business for fiscal years, as well as in timekeeping.

International Standards Organization years; standardizing date-time formats across various UNIX systems. Many people from Europe, for example, prefer the month to be stated after the day of the month. "2 January YYYY" whereas in other places (in formal writings) people prefer the month to be written first: "January 2, YYYY". Sometimes (if, for example, running virtual host) they can appear to be a mix-up since there's quite a bit of ambiguity within the %m%d%H%_M% or "%m%d%H(M)" string sequences.

For sources, see also "errata" on intuitive.com/wicked

when the correct time to use them is?

Basically amounts to personal preference since options can be formatted.

That doesn't really answer the question they were trying to ask, but other replies do.

Reply on news.ycombinator.com