dayofyear is not great when going into a new year

Eli the Bearded * at eli.users.panix.com
Tue Jan 5 20:38:09 EST 2021


In comp.lang.python, Mats Wichmann  <mats at wichmann.us> wrote:
> "workweeks" has always been fun, ISO standard or not, there's been a 
> variation for ages since people don't seem to always follow ISO for 
> that.  I spent over a decade at a place that lived and died by their 
> WorkWeek references ("due WW22" or the like would appear in every status 
> report ever written, and there were zillions of those) - and it didn't 
> agree with ISO on whether WW1 was the week that contained Jan 1 or 
> whether it was the week that followed the previous year's last workweek. 
> After all, those few days can't actually belong to two different 
> workweeks, now can they?  :)

I think the ISO standard was to try to unify a bunch of inconsistent
locally defined things like that. In Gnu date(1), there are THREE
different, and sometimes the same and sometimes not, week of year
codes:

   %U     week number of year, with Sunday as first day of week (00..53)

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

   %W     week number of year, with Monday as first day of week (00..53)

I don't think that is an exhaustive list of methods used, either.

(excuse the vi command ugliness; % is special to : commands in vi)

:r! date +"U: \%U; V: \%V; W: \%W"
U: 01; V: 01; W: 01

Today they all match. But not always.

:r! date --date="Jan 02 2005" +"U: \%U; V: \%V; W: \%W"
U: 01; V: 53; W: 00

> (that was not a good memory you guys brought back :) )

Oh what a tangled web we weave, when we first begin to [measure time].

Elijah
------
they all disagree for Jan 02 2022, too, but slightly differently


More information about the Python-list mailing list