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