Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timestamp-like strings lose quote #889

Open
deblaci opened this issue Jan 22, 2024 · 6 comments
Open

Timestamp-like strings lose quote #889

deblaci opened this issue Jan 22, 2024 · 6 comments
Assignees
Labels
blocked on upstream Feature is blocked on upstream project bug This issue describes a defect or unexpected behavior carvel accepted This issue should be considered for future work and that the triage process has been completed

Comments

@deblaci
Copy link

deblaci commented Jan 22, 2024

What steps did you take:

When I provide a string but contains timestamp, after templating with Ytt this strings lose the quote.
This would be valid, but yaml parsers handle this as a date not a string and convet it like Mon Sep 20 12:00:00 CEST 2021.
This happens even I turn on strict yaml, according to rule "requires strings with colon to be explicitly quoted"

template.yaml:
exampleTimestamp: "2023-01-01T07:00:00"

ytt -f template.yaml
ytt -f template.yaml -s

What happened:

exampleTimestamp: 2023-01-01T07:00:00

What did you expect:

exampleTimestamp: "2023-01-01T07:00:00"

Environment:

  • ytt version (use ytt --version): ytt version 0.47.0
  • OS (e.g. from /etc/os-release):
    ProductName: macOS
    ProductVersion: 14.2.1
    BuildVersion: 23C71

Vote on this request

👍 "I would like to see this addressed as soon as possible"

@deblaci deblaci added bug This issue describes a defect or unexpected behavior carvel triage This issue has not yet been triaged for relevance labels Jan 22, 2024
@prembhaskal
Copy link
Member

checking...

@prembhaskal
Copy link
Member

prembhaskal commented Jan 22, 2024

@deblaci
I think your timestamp format is not correct (either it needs a timezone or a space between date and time).
Which is the other yaml parser your are using which is parsing the unquoted string as timestamp?
ytt (actually the underlying go.yaml parser) encloses data in quotes if it finds a valid timestamp

 % cat timestamp.yaml 
canonicalts: "2023-01-01T07:00:00.1Z"
canonicalts1: 2023-01-01T07:00:00.1Z
iso8601ts: "2023-01-01T07:00:00Z"
iso8601ts1: 2023-01-01T07:00:00Z
withspacets: "2023-01-01 07:00:00"
withspacets1: 2023-01-01 07:00:00

 % ytt -f timestamp.yaml 
canonicalts: "2023-01-01T07:00:00.1Z"
canonicalts1: "2023-01-01T07:00:00.1Z"
iso8601ts: "2023-01-01T07:00:00Z"
iso8601ts1: "2023-01-01T07:00:00Z"
withspacets: "2023-01-01 07:00:00"
withspacets1: "2023-01-01 07:00:00"

@prembhaskal
Copy link
Member

@prembhaskal prembhaskal self-assigned this Jan 22, 2024
@deblaci
Copy link
Author

deblaci commented Jan 22, 2024

@prembhaskal
Thanks for checking.

According to (https://yaml.org/type/timestamp.html), "2023-01-01T07:00:00" seems to be valid. I tried the regex.
But If I would agree with the above timestamp is wrong, the above timestamp needs to be considered as a String.

Shouldn't Ytt generate a strict yaml in strict mode?

When I use Ytt in Strict mode, I give strict input yaml then I will get a non-strict yaml, since "exampleTimestamp: - 2023-01-01T07:00:00" is not a strict yaml without quote. (https://carvel.dev/ytt/docs/v0.46.x/strict/)

ytt: Error: Unmarshaling YAML template 'temp-yaml': • yaml:
Strict parsing:
Strings with colon must be explicitly quoted: • '2023-01-01T07:00:00'

I tried to parse the yaml with Groovy:
import org-yaml.snakeyaml.Yaml
new Yaml(). load(yamlContent)
With Jenkins readYaml has same result

@prembhaskal
Copy link
Member

@deblaci so strict yaml is only for parsing.
mainly we use strictdecoder of yaml library to achieve this. there is no encoder for strict output generation.

@renuy renuy moved this to To Triage in Carvel Feb 6, 2024
@renuy renuy added blocked on upstream Feature is blocked on upstream project carvel accepted This issue should be considered for future work and that the triage process has been completed and removed carvel triage This issue has not yet been triaged for relevance labels Feb 6, 2024
@renuy
Copy link

renuy commented Feb 6, 2024

Upstream does not have this feature.
We will try and find cycles to patch upstream.

@renuy renuy moved this from To Triage to Unprioritized in Carvel Feb 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked on upstream Feature is blocked on upstream project bug This issue describes a defect or unexpected behavior carvel accepted This issue should be considered for future work and that the triage process has been completed
Projects
Status: Unprioritized
Development

No branches or pull requests

3 participants