calendar(1) can have input in various encoding, specifying
LANG=<locale_name> to enable calendar(1) to determine which one to use.
The problem is the content of the calendar itself is exposed as is making it
unreadable in many cases. For example french calendar which is encoded
ISO8859-1 is rendered badly in a fr_FR.UTF-8 environment.
Using iconv allows to solve this issue.
This will also allow to keep only 1 encoding in base for those files without
breaking user existing setup
Reported by: many
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D19221
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96
Support includes surrounded by '"' or '<' '>'
Print warnings about bad syntax
Correctly navigate through include directories to find calendar files
Correctly support multiple includes
Tested by: gjb
MFC after: 1 week
Explicitly use GNU cpp for preprocessing.
Remove explicit debugging code.
Change some variable names to be less confusing.
Improve some comments.
Improve indentation.
PR: 162211
168785
MFC after: 2 weeks
- Remove the 3rd clause of the UC Berkeley copyrighted files.
- For the files added copyrighted by me, move the "All rights
reserved" to the next line.
- Repeating events which span multiple years (because of -A, -B or
just the three days before the end of the year).
- Support for lunar events (full moon, new moon) and solar events
(equinox and solstice, chinese new year). Because of this, the
options -U (UTC offset) and -l (longitude) are available to
compensate if reality doesn't match the calculated values.
MFC after: 1 month
Correct long-standing off-by-one error in -W option.
Submitted by: edwin@
Shorten some long lines. These files are still not completely
style(9) compliant.
-W is like -A (number of days in the future to consider, but also
specifies that we don't want special treatment at weekends.
-F changes our notion of "Friday" (the day before the weekend).
Arguably, calendar(1) is broken to have special treatment of weekends
by default, but this method maintains POLA.
o main returns int not void
o use return 0 at end of main when needed
o use braces to avoid potentially ambiguous else
o don't default to type int
o #ifdef 0 -> #if 0
Reviewed by: obrien and chuckr
E.g. for Easter, and entries like "04/SunFirst" calendar will
now report:
04/05* Good Friday (2 days before easter)
04/07* First Sunday...
instead of:
Easter-2 Good Friday...
04/SunFirst First Sunday...
I also modified the calendar files to use the variable day format
for a lot of events so that they will be reported correctly.
E.g. U.S. daylight savings time is now listed as:
04/SunFirst Daylight savings time...
There are still a lot of wrong dates in there for some events
that move from year to year, but I don't have a good calendar handy
right now that I can use for reference.
