Feature request: Improve date and time formatting in "Parse X.509 certificate"
- Dominant language
- JavaScript
- Stars
- 35.8k
- Forks
- 4.1k
- Avg merge
- 2d 26m
- Merged PRs (30d)
- 33
Description
X.509 certificates have start and end dates that are displayed in human readable format by the Parse X.509 certificate operation. For example, the [current Github TLS certificate](https://gchq.github.io/CyberChef/#recipe=Parse_X.509_certificate('PEM')&input=LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUZhakNDQlBDZ0F3SUJBZ0lRQlJpYVZPdm94K2tENEtzTmtsVkYzakFLQmdncWhrak9QUVFEQXpCV01Rc3cKQ1FZRFZRUUdFd0pWVXpFVk1CTUdBMVVFQ2hNTVJHbG5hVU5sY25RZ1NXNWpNVEF3TGdZRFZRUURFeWRFYVdkcApRMlZ5ZENCVVRGTWdTSGxpY21sa0lFVkRReUJUU0VFek9EUWdNakF5TUNCRFFURXdIaGNOTWpJd016RTFNREF3Ck1EQXdXaGNOTWpNd016RTFNak0xT1RVNVdqQm1NUXN3Q1FZRFZRUUdFd0pWVXpFVE1CRUdBMVVFQ0JNS1EyRnMKYVdadmNtNXBZVEVXTUJRR0ExVUVCeE1OVTJGdUlFWnlZVzVqYVhOamJ6RVZNQk1HQTFVRUNoTU1SMmwwU0hWaQpMQ0JKYm1NdU1STXdFUVlEVlFRREV3cG5hWFJvZFdJdVkyOXRNRmt3RXdZSEtvWkl6ajBDQVFZSUtvWkl6ajBECkFRY0RRZ0FFU3JDVGNZVWg3R0kveTNUQVJzam5BTnduU2pKTGl0VlJnd2dSSTFKbHhaMWtkWlFRbjVsdFAzdjcKS1R0WXVEZFVlRXUzUFJ4M2ZwRGR1MmNqTWx5QTBhT0NBNDR3Z2dPS01COEdBMVVkSXdRWU1CYUFGQXE4Q0NrWApqS1U1YlhvT3pqUEhMclB0KzhONk1CMEdBMVVkRGdRV0JCUjRxbkxHY1dsb0ZMVlpzWjZMYml0QWgwSTdIakFsCkJnTlZIUkVFSGpBY2dncG5hWFJvZFdJdVkyOXRnZzUzZDNjdVoybDBhSFZpTG1OdmJUQU9CZ05WSFE4QkFmOEUKQkFNQ0I0QXdIUVlEVlIwbEJCWXdGQVlJS3dZQkJRVUhBd0VHQ0NzR0FRVUZCd01DTUlHYkJnTlZIUjhFZ1pNdwpnWkF3UnFCRW9FS0dRR2gwZEhBNkx5OWpjbXd6TG1ScFoybGpaWEowTG1OdmJTOUVhV2RwUTJWeWRGUk1VMGg1ClluSnBaRVZEUTFOSVFUTTROREl3TWpCRFFURXRNUzVqY213d1JxQkVvRUtHUUdoMGRIQTZMeTlqY213MExtUnAKWjJsalpYSjBMbU52YlM5RWFXZHBRMlZ5ZEZSTVUwaDVZbkpwWkVWRFExTklRVE00TkRJd01qQkRRVEV0TVM1agpjbXd3UGdZRFZSMGdCRGN3TlRBekJnWm5nUXdCQWdJd0tUQW5CZ2dyQmdFRkJRY0NBUlliYUhSMGNEb3ZMM2QzCmR5NWthV2RwWTJWeWRDNWpiMjB2UTFCVE1JR0ZCZ2dyQmdFRkJRY0JBUVI1TUhjd0pBWUlLd1lCQlFVSE1BR0cKR0doMGRIQTZMeTl2WTNOd0xtUnBaMmxqWlhKMExtTnZiVEJQQmdnckJnRUZCUWN3QW9aRGFIUjBjRG92TDJOaApZMlZ5ZEhNdVpHbG5hV05sY25RdVkyOXRMMFJwWjJsRFpYSjBWRXhUU0hsaWNtbGtSVU5EVTBoQk16ZzBNakF5Ck1FTkJNUzB4TG1OeWREQUpCZ05WSFJNRUFqQUFNSUlCZndZS0t3WUJCQUhXZVFJRUFnU0NBVzhFZ2dGckFXa0EKZGdDdDk3NzZmUDhReUl1ZFBad2VQaGhxdEdjcFhjK3hEQ1RLaFlZMDY5eUNpZ0FBQVgrT2k4U1JBQUFFQXdCSApNRVVDSUFSOWNObnZZa1plS3M5SkVscGVYd3p0WUIyeUxodGM4YkIwclkya2U5OG5BaUVBamlNTDhIWjdhZVZFClAvRGtVbHR3SVM0YzczVlZyRzlKZ3VvUnJJSTdnV01BZHdBMXp4a2J2N0ZzVjc4UHJVeHRRc3U3dGljZ0psSHEKUCtFcTc2Z0R3enZXVEFBQUFYK09pOFI3QUFBRUF3QklNRVlDSVFETmNrcXZCaHVwN0dwQU5NZjBXUHVleXRMOAp1L1BCYUlBT2J6TlplTk1wT2dJaEFNamZFdEU2QUoyZlRqWUNGaC9CTlZLazFta1R3QlRhdkpsR21Xb21ReWFCCkFIWUFzM04zQitHRVVQaGpodFlGcWR3UkNVcDVMYkZuREF1SDNQQUREbmsycFpvQUFBRi9qb3ZFckFBQUJBTUEKUnpCRkFpRUE5VWo1RWQvWGpRcGovTXhRUlFqekcwVUZRTG1nV2xjNzNubnQzQ0o3dnNrQ0lDcUhmQktsRHo3UgpFSGRWNVZrOGJMTUJXMVE2UzdHYTJTYkZ1b1ZYczZ6Rk1Bb0dDQ3FHU000OUJBTURBMmdBTUdVQ01DaVZocWZ0CjdML3N0Qm12MVhxU1JOZkUvakcvQXFLSWJtakdUb2NOYnVRN2t0MUNzN2tSZytiM2IzQzlJcHU1RlFJeEFNN2MKdEdLcllER3QwcEg4aUY2cnpicDlRNEhRWE1aWGtOeGcrYnJqV3huYU9WR1RETndOSDcwNDgrcy9oVDliVVE9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg) displays:
```
Validity
Not Before: 15/03/2022 00:00:00 (dd-mm-yyyy hh:mm:ss) (220315000000Z)
Not After: 15/03/2023 23:59:59 (dd-mm-yyyy hh:mm:ss) (230315235959Z)
```
I'd prefer a different date format, e.g. ISO 8601 date or having the month spelled out. As an American, American-style is acceptable for me but I don't prefer it over other options.
Additionally, including an indication of time zone might be a good idea. Windows displays X.509 dates in local time while Cyberchef uses Zulu/UTC.
OpenSSL 1.0.2 and 3.0.2 use a format with GMT (which is wrong in my opinion- UTC is preferred):
```
Validity
Not Before: Mar 15 00:00:00 2022 GMT
Not After : Mar 15 23:59:59 2023 GMT
```
Contributor guide
Research direction
Start from the Parse X.509 certificate operation and inspect how the Not Before and Not After validity dates are currently rendered. Clarify the desired date format and UTC/time-zone indication, then verify that both certificate dates consistently use the agreed presentation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100