Question
Can GitBook apply a custom timezone to dates in exported PDF or ePub files?
Mira Byte
0 reputation · 09 Sept 2020, 04:10 UTC
68K views1
Loading…
0 reputation · 09 Sept 2020, 04:10 UTC
When publishing content, GitBook stores all date metadata such as lastModified and publishDate in UTC ISO 8601 format. The viewer’s browser then converts these timestamps to local time using the Intl.DateTimeFormat API, so readers see times adjusted to their own zone.
However, exporting a page to PDF or ePub appears to use the server’s UTC value directly, without applying any regional offset, and there is no documented site‑wide setting or frontmatter property to override this behavior.
Goal: ensure that exported documents display dates in a consistent timezone that matches the intended audience, regardless of where the build server runs.
Is there a configuration option or frontmatter field to force a specific timezone for PDF/ePub export? If not, can a custom export template or plugin be used to adjust timestamps before generation? Are there plans to add timezone‑aware formatting to the export pipeline?
35275 reputation · 09 Sept 2020, 13:55 UTC
No, GitBook does not provide a setting or frontmatter field to force a specific timezone for dates in exported PDF or ePub files.
gitbooktemplates/ or referenced in book.json).{{ date | date:'yyyy-MM-dd HH:mm:ss Z' }} in the templating language.gitbook pdf ./ or gitbook epub ./) and verify the dates appear with the desired offset.To determine whether the above workaround applies, please let me know if you are using GitBook.com (hosted) or a self‑hosted GitBook installation.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 09 Sept 2020, 12:29 UTC
One clarification worth adding to the answer above: the template-editing workaround only applies to legacy self-hosted GitBook (v3.x), which is end-of-life. On the current GitBook.com platform there is no template or hook system for the PDF/ePub pipeline at all, so timestamps cannot be intercepted before generation.
A more portable workaround is to stop relying on auto-rendered metadata and write dates as literal strings in the page body, e.g. Published 12 March 2026, 09:00 CET. Body content is exported verbatim, so the string survives PDF/ePub generation unchanged. If your content comes from Git Sync, you control the source frontmatter and can normalize or pre-offset ISO strings in the repository before GitBook ingests them.
The trade-off: literal strings also disable the browser-side localization that web readers currently get, so the display becomes fixed everywhere. Verify by exporting a test page with a known UTC timestamp and comparing web, PDF, and ePub output. Also check GitBook's changelog or support channels, since export behavior may have changed recently.