mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Currently there is no way easy way to determine the week number of the year. As in Week 1, Week 2... Week 52, Week 53.

ISO 8601 states that the first day of the new week is Monday. It also states that the first week of the year is the first week that contains a Thursday, or in other words, if the Jan 01 of the year is a Friday, Saturday or Sunday then that day is Week 52 or Week 53 of the previous year and the following Monday begins Week 01. (Internally, you can write this off as Week Zero(0) unless the date passed is Jan 01, 02 or 03 and then you have to figure out how many weeks are in the previous year.)

$asctime($ctime, w) == 1 ... 53
$asctime($ctime, ww) == 01 ... 53


ISO compliant output portrays the string "2014-W09"
as in $asctime($ctime, yyyy-Www) or $asctime($ctime, yyyy) $+ -W $+ $asctime($ctime, ww)

Because this function would require knowledge of the Day-of-Year (1-366), could we also get $asctime() to return this value as well?


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Jan 2004
Posts: 2,127
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
I had once started writing up a feature request for improvement to the $asctime format codes, but I don't think I actually posted it because I ran into problems of figuring out how to design $asctime in a way that preserves backwards compatibility between newer and older behavior.

//echo -a $asctime($calc(978307200+3600+61+$daylight +$timezone),$regsubex(foo,$str(x,94),/x/g,$chr($calc(32+ \n ))))

This shows that the current behavior of $asctime formatting is to substitute codes in place of recognized letters, but to leave unrecognized letters alone. The exception is that the % character is deleted from the output. This means that adding new symbols like w or W could cause differences in behavior between scripts running under newer versions recognizing more codes compared to older versions which don't.

$asctime(123, wtf)

Under versions where 'w' has no interpreted meaning, it shows the literal 'w'. Under newer versions recognizing 'w' as an ISO week, it would be impossible to show a literal 'w', just like it's impossible to allow a "T" in the formatting to being shown as a literal "T" instead of being interpreted as A or P.

A happy medium would be to allow the double quote character to enclose text that's immune to being translated. so

//echo -a $asctime($ctime, HH:nn:ss $+(",$me local time") on mm/dd/yy )

would show everything inside the doublequotes without being interpreted and without showing the doublequotes themselves.

I don't know what an intentional purpose could be for having $asctime formatting swallow the percent character, so I'm guessing it's probably a bug in a routine that's not expecting an embedded % character to survive after interpreting variable names into their contents.

//echo -a $asctime(123,a%b%c%)

..simply swallows the percents and displays the abc alone.

If a 'week' symbol is added I wonder if that would have people wanting to use it for logging filenames. That would let them have 'weekly' logs which always start on the same day of the week, instead of having one of their logs ranging from day 21-28 in some months or being day 21-31 in other months.

I wonder if users would have less use for ISO week/days, or more use for week-numbers which always begin on a Sunday instead of on a Monday, or for day-of-the-year where day 1 is always Jan 1st, and Dec 31 is always day 365 or 366 depending on whether it was a leap year. Having ISO functions for the week would probably also need ISO year codes which indicate which ISO year a particular Dec 31 falls in.


Link Copied to Clipboard