govuk_app_config 9.17.13 → 9.17.14
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/.gitignore +0 -1
- data/CHANGELOG.md +4 -0
- data/doc/adr/0001-timezone-usage-across-gov-uk.md +60 -0
- data/lib/govuk_app_config/version.rb +1 -1
- metadata +2 -1
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: f041acc0e178ba68e8298ddbe9f17bc59d371ef7284431514c85e056ea3ebb1b
|
|
4
|
+
data.tar.gz: c9a95a51c8857e3979a0c89ab565360b0793aa09e27834d85c43b3aade4d7f50
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: 11f1ef0618f06fde24cbe61e25de5a24bcf439306b6856af38c4612b3640532b3ef222977e2d29f196948e91dacb3477aefb0e75bc4633d70578d59c51775d11
|
|
7
|
+
data.tar.gz: f0eb53295301211a6c8d2bd37d0b67702f83899eda193334212e399c399a2fbb5ea02f571858ace0ec80581b9d1b30df281c6bcc6e2f8926bfcfd3208f650995
|
data/.gitignore
CHANGED
data/CHANGELOG.md
CHANGED
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
# 1. Timezone usage across GOV.UK
|
|
2
|
+
|
|
3
|
+
Date: 2025-06-27
|
|
4
|
+
|
|
5
|
+
## Status
|
|
6
|
+
|
|
7
|
+
Accepted
|
|
8
|
+
|
|
9
|
+
## Context
|
|
10
|
+
|
|
11
|
+
Within the landscape of GOV.UK, we have 3 main categories of deployables: Publishing Apps, API Services, Frontend Apps.
|
|
12
|
+
|
|
13
|
+
Timestamps are being passed between these apps and services. We need a consistent decision in handling timezones so we do not end up displaying the wrong date during British Summer Time where are we one hour out of sync with UTC.
|
|
14
|
+
|
|
15
|
+
## Decision
|
|
16
|
+
|
|
17
|
+
The decision is for all `Publishing Apps` and `Frontend Apps` to default to `London` timezone (which will switch to BST during summer, and UTC during winter); and for all `API Services` to default to UTC. Reasons and some exceptions to the rule are listed below.
|
|
18
|
+
|
|
19
|
+
This means all apps need to parse Date and Timestamp with timezone parsing. More on this in `Consequences` section.
|
|
20
|
+
|
|
21
|
+
### Reasonings
|
|
22
|
+
|
|
23
|
+
- In most cases, we use London as the timezone.
|
|
24
|
+
We make an exception for APIs, where we mostly want to provide UTC dates. A major reason for not migrating APIs to London timezone is because migrating major services like `Publishing API` may have consequences that we have yet to fully analyse.
|
|
25
|
+
- We also make an exception for travel advice publisher which is a `Publishing App` which operates in UTC. `Travel Advice Publisher` has users in lots of different local timezones. If we can improve the app to display in appropriate timezones we may be able to migrate it to use default London as other publishing apps do.
|
|
26
|
+
|
|
27
|
+
### Exceptions
|
|
28
|
+
|
|
29
|
+
All `Publishing Apps` and `Frontend Apps` are in `London` timezone except*:
|
|
30
|
+
|
|
31
|
+
| App | Timezone | Reason |
|
|
32
|
+
|---|---|-------------------------------------------------------------------------------------------------------|
|
|
33
|
+
| Travel Advice Publisher | UTC | Publishers are publishing for many different timezones in which London timestamps may cause confusion |
|
|
34
|
+
|
|
35
|
+
All `API Services` are in `UTC` timezone except*:
|
|
36
|
+
|
|
37
|
+
| API | Timezone | Reason |
|
|
38
|
+
|-----------------|----------|-----------------------|
|
|
39
|
+
| Email Alert API | London | Has not been migrated |
|
|
40
|
+
|
|
41
|
+
|
|
42
|
+
*A full audit has yet to be conducted to ensure all our applications and APIs adhere to the above.
|
|
43
|
+
|
|
44
|
+
## Consequences
|
|
45
|
+
|
|
46
|
+
With the discrepancy that Publishing Apps and Frontends operate in `London` timezones, but APIs operate in `UTC`, we run the risk of displaying wrong information to Publishers and the Public if we are parsing timestamps without their timezones.
|
|
47
|
+
|
|
48
|
+
Take the following Example scenario:
|
|
49
|
+
|
|
50
|
+
- Publishing App schedules article to publish at midnight BST, e.g. `01-07-2025 00:00 BST` which is equivalent to the day before in UTC `30-06-2025 23:00 UTC`
|
|
51
|
+
- This is sent to Publishing API and subsequently Search API
|
|
52
|
+
- Publishing time set in Publishing API and Search API as `30-06-2025 23:00 UTC`
|
|
53
|
+
- Frontend needs to parse the Date to display as Publication date.
|
|
54
|
+
- If the Date is simply parsed as `Date.parse(publication_date)` we get `30-06-2025` which is the **wrong** date.
|
|
55
|
+
- We **must** parse in the zone before extracting the date. E.g. `Time.zone.parse(publication_date).to_date` to get the correct date `01-07-2025`
|
|
56
|
+
|
|
57
|
+
## Actions yet to take
|
|
58
|
+
|
|
59
|
+
- Do a full audit of which Timezone each Service or App operate in to identify exceptions to the rule
|
|
60
|
+
- Implement a linter guard to ensure we are not trapped in situations such as the one detailed above under `Consequences`. e.g. Error or Warn on all plain `Date.parse` or `Chronic` date parsing without timezone configured.
|
metadata
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
|
2
2
|
name: govuk_app_config
|
|
3
3
|
version: !ruby/object:Gem::Version
|
|
4
|
-
version: 9.17.
|
|
4
|
+
version: 9.17.14
|
|
5
5
|
platform: ruby
|
|
6
6
|
authors:
|
|
7
7
|
- GOV.UK Dev
|
|
@@ -352,6 +352,7 @@ files:
|
|
|
352
352
|
- Rakefile
|
|
353
353
|
- bin/console
|
|
354
354
|
- bin/setup
|
|
355
|
+
- doc/adr/0001-timezone-usage-across-gov-uk.md
|
|
355
356
|
- docs/healthchecks.md
|
|
356
357
|
- govuk_app_config.gemspec
|
|
357
358
|
- lib/govuk_app_config.rb
|