RE: [tosca] Clarification required for "!!timestamp" type in YAML

[Chris Lauwers <lauwers@ubicity.com>]

Hi Tal,

 

These are good comments, but unfortunately I think thatâs just how YAML works: parsers will try their best to determine the intended type of a value, and theyâre not always right. The simplest example I run into all the time is version strings. Letâs assume I specify a version of 2.5. Without quotes, YAML parsers will invariably turn this version string into a floating point number.

If there is a chance of confusion, the user needs to explicitly âmark upâ the value with the intended type.

 

Chris

 

From: Tal Liron [mailto:tliron@redhat.com]
Sent: Tuesday, October 01, 2019 11:24 AM
To: Chris Lauwers
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] Clarification required for "!!timestamp" type in YAML

 

On Mon, Sep 30, 2019 at 11:17 PM Chris Lauwers <lauwers@ubicity.com> wrote:

The python ruamel.yaml parser appears to handle these correctly with or without the !!timestamp tag. I tried the 5 examples in https://yaml.org/type/timestamp.html and in none of the cases does the parser give me a raw âstringâ. Depending on the example, I get a TimeStamp object (which is an internal ruamel object), a (python) datetime.datetime, or a (python) datetime.date  I need to dig a little deeper to see whatâs inside the TimeStamp object, but on the surface it looks like this is handled correctly.

 

That's good news, but it is a bit curious as to why different objects are created in different cases.

 

I'm also not sure if it's great behavior -- this means that for *every* string, ruamel.yaml tries to see if it can be parsed as a timestamp, and if so encapsulates it as an internal Python object. But what happens if the timestamp is somehow encoded incorrectly by the user? The result would be a string, rather than an error message about a malformed timestamp. And what if it's not intended to be a timestamp, but a string that happens to look like one? Do you have to wrap in quotation marks to make sure it's decoded as a string? My understanding was that you have to explicitly use "!!timestamp" in YAML, not have it automatically interpreted as such. But perhaps I'm wrong? I can't find this in the YAML spec.

 

It would be interesting to see how ruamel.yaml handles round-trips in these cases. If it creates a timestamp object from a string, does it actually encode using "!!timestamp" as the end result? This might again result in something different from what the user intended, especially if the end result is canonicalized in some way, resulting in a different string.