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

[Chris Lauwers <lauwers@ubicity.com>]

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 said, I strongly agree that a TOSCA parser/validator should accept a timezone value without the !!timezone tag, even if that means that the parser needs to do the conversion and validation itself.

 

Thanks,

 

Chris

 

 

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of Tal Liron
Sent: Monday, September 30, 2019 8:48 AM
To: tosca@lists.oasis-open.org
Subject: [tosca] Clarification required for "!!timestamp" type in YAML

 

Currently the spec (1.3, but before that, too) shows all examples of timestamps as strings. E.g. in 5.3.7.3.1:

 

properties:
  description:
  evaluation_period: Evaluate a service for a 5-day period across time zones
    type: TimeInterval
    start_time: 2016-04-04-15T00:00:00Z
    end_time: 2016-04-08T21:59:43.10-06:00

 

But the spec also states that we use YAML's "!!timestamp" format. So if we follow the spec as it is we should really be writing this as follows:

 

properties:
  description:
  evaluation_period: Evaluate a service for a 5-day period across time zones
    type: TimeInterval
    start_time: !!timestamp 2016-04-04-15T00:00:00Z
    end_time: !!timestamp 2016-04-08T21:59:43.10-06:00

 

If we don't do so, then the YAML parser would evaluate the value as a string with no special validation, and the TOSCA parser would then need to parse this string and validate that is in the accepted timestamp format.

 

I would think we would all agree that requiring "!!timestamp" is unnecessarily verbose and specific for the purposes of TOSCA, and that we would want to accept strings as well. There's actually a further issue with "!!timestamp": I've found that YAML parsers do not consistently parse according to the YAML format, which is actually not quite standard. For example, I've found that not all YAML parsers would succeed in parsing the space-separated format: "2001-12-14 21:59:43.10 -5". It's too easy and lazy to just use the language's (Python, Ruby, Go, etc.) internal time parser. (This should be considered a bug in your YAML parser, so please report it if you find it!)

 

If we agree about allowing strings, as I am suggesting, then we must be explicit about this in the spec. Either way this needs to be clarified.

Furthermore, for those of us implementing TOSCA parsers, I recommend that you test that you can indeed support both "!!timestamp" and strings and that you get the same results in both cases. In my case (Puccini) I have implemented my own timestamp parser exactly for this use case, but also have a separate codepath to check for the internal Go type used by the YAML parser (time.Time).