- JavaScript 52.7%
- HTML 29%
- CSS 12.6%
- Nix 4.6%
- Shell 1.1%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
Hauke Mehrtens
cd39842ac0
`toLocaleString()` was given the German locale but no time zone, so it printed
the time in whatever zone the browser of the visitor is set to. The events
happen in Berlin, so this is only correct for visitors who are in Berlin.
Somebody reading the start page from Sydney was told the Plenum of Tuesday
20:00 takes place on Wednesday at 04:00.
Format in Europe/Berlin explicitly. For an event that names a point in time
only the printing was wrong, picking and sorting work on absolute points in
time and were not affected.
An all day event carries a date, and a date has neither a time nor a zone: its
digits are the day itself. `toJSDate()` reads them as midnight in the zone of
the browser, so the point in time that is then printed in Berlin time is off by
the offset between the two, which puts a bogus time of day on the entry and,
far enough east or west, the wrong day. An event on 30.08. was announced as:
Berlin Sonntag, 30.08., 00:00 Uhr
Los Angeles Sonntag, 30.08., 09:00 Uhr
Tokio Samstag, 29.08., 17:00 Uhr
Keep the digits of the date and read them as UTC, which no browser setting
moves, and print an all day event in UTC and without a time of day. Berlin,
Tokyo, Los Angeles and Kiritimati all say "Sonntag, 30.08." now, while a timed
event keeps saying "Sonntag, 30.08., 19:00 Uhr" everywhere. Sorting improves
with it, an all day event no longer changes its place in the list depending on
where the visitor sits.
The published calendar has no all day events today, they can be created in the
CalDAV calendar the export comes from.
Drop the two replacements around the formatted date while touching it. The
first removes the comma after the weekday and the second puts it back, so they
cancel each other out:
"Samstag, 22.08., 17:00" -> "Samstag 22.08., 17:00" -> "Samstag, 22.08., 17:00"
Fixes:
|
||
| .forgejo/workflows | ||
| archetypes | ||
| assets | ||
| config/_default | ||
| content | ||
| i18n | ||
| layouts | ||
| static | ||
| themes | ||
| tools | ||
| .editorconfig | ||
| .gitignore | ||
| .gitmodules | ||
| .hugo-params | ||
| build.sh | ||
| devShells.nix | ||
| flake.lock | ||
| flake.nix | ||
| LICENSE | ||
| old_config.yaml.txt | ||
| packages.nix | ||
| README.md | ||
| TODO.md | ||
CCCB Website
This is the website of the CCCB.
Getting started
-
Clone this repo (
--recursiveis needed to check out submodules)git clone --recursive https://git.berlin.ccc.de/cccb-website-team/www.git cccb-website -
Switch directory
cd cccb-website -
Run hugo webserver
hugo serve -
Point your browser to: http://localhost:1313/
Every change you make on the project will be reflected in your browser as long as hugo serve is running.
The "Nächste Veranstaltungen" table on the home page and the calendar under /verein/calendar/ are rendered in the
browser by static/js/upcoming.js and assets/js/calendar.js. Both fetch /calendars/all.ics, which is not
generated by Hugo and is not part of this repo — it is published separately on the web server. Without it both tables
stay empty. Download the published calendar into static/, which Hugo serves under the same path, and they work
locally, under hugo serve as well as in a built site:
mkdir -p static/calendars
curl -o static/calendars/all.ics https://berlin.ccc.de/calendars/all.ics
The file is only there to look at the site, it is not checked in. Download it again whenever you want the events that are currently published.
Hugo does generate an .ics feed per section (for example /veranstaltungen/index.ics) from the dtstart, dtend
and rrule front matter of the pages in content/veranstaltungen/, using the .ics templates under layouts/.
To build the site for upload, run:
./build.sh
This deletes public/ and runs hugo with the parameters from .hugo-params. To build with nix instead:
nix build '.?submodules=1#production-content'
Making a change
- Use your local dev setup (see Getting started) or via the Forgejo editor.
- Make your change in
stagingbranch. - Commit (and push) your change.
GitHub Actions is running the release workflow.- If successful, check Staging Website if change is correct.
- Create a merge request to merge changes from
stagingtoproductionbranch. Ask somebody to check merge request or if small change, merge yourself. GitHub Actions is running the release workflow.- If successfull, check Website if change is correct.
- Profit!
Nix stuff
- After entering the shell with
nix develop, hugo is available andhugo serveand./build.shshould work - You can build the staging and production builds with
nix build .#staging-contentandnix build .#production-content - Do not update the nixpkgs branch - 25.05 contains a newer hugo version that is incompatible with the theme (last checked June 2025)
Made with ❤️ and Hugo.