Order matters in date time comparisons

[djmcgreal-cc]

Describe the bug

I had a date come in as a string, e.g. Expiration: "2023-01-30T15:53:09Z" that I wanted to check against now. I found that it only worked if I put now as the first argument, e.g. now < .Expiration works but .Expiration > now fails with

!!str not yet supported for comparison

Before I found that the ordering matters, I had tried to

• force the str to be a timestamp with .Expiration tag="timestamp", but that resulted in the same error (although it was tagged in the output)
• remove the "s, but I couldn't work out how to do that with style, ="" didn't change the output any

Version of yq: 4.29.2
Operating system: mac
Installed via: homebrew

Input Yaml
Concise yaml document(s) (as simple as possible to show the bug, please keep it to 10 lines or less)
data1.yml:

Expiration: "2023-01-30T15:53:09Z"

Command
The command you ran:

yq -e '.Expiration > now'

Actual behavior

Error: !!str not yet supported for comparison

Expected behavior

true

(or false...)

[mikefarah]

Because you have quotes around the timestamp, yq thinks it's a string. If you remove the quotes, then it will have the correct type (timestamp).

It works the otherway around, because it knows now is a timestamp, so it tries to parse the 2nd arg as a timestamp as well...

[djmcgreal-cc]

Thanks Mike, I understand. I did try to remove the quotes with `style` but couldn’t find a way of doing it. Perhaps either that or the importance of ordering in comparison operations could be documented? From: Mike Farah ***@***.***> Date: Tuesday, 31 January 2023 at 03:20 To: mikefarah/yq ***@***.***> Cc: Dan McGreal ***@***.***>, Author ***@***.***> Subject: Re: [mikefarah/yq] Order matters in date time comparisons (Issue #1537) **EXTERNAL EMAIL**

…

________________________________ Because you have quotes around the timestamp, yq thinks it's a string. If you remove the quotes, then it will have the correct type (timestamp). It works the otherway around, because it knows now is a timestamp, so it tries to parse the 2nd arg as a timestamp as well... — Reply to this email directly, view it on GitHub<https://protect-us.mimecast.com/s/sqodC5ygLXsZkK8rizy9ZD?domain=github.com>, or unsubscribe<https://protect-us.mimecast.com/s/kKg1C68j94hrL9k4U6TmAc?domain=github.com>. You are receiving this because you authored the thread.Message ID: ***@***.***> This email, including attachments, contains confidential information belonging to Cambridge Consultants. It is intended for the addressee only and may only be copied or disclosed to others with permission. If you are not the intended recipient please delete the material from any computer. Emails are subject to monitoring for legal and security purposes. If this email has been sent as a personal message the company accepts no liability for the content.

[mikefarah]

Actually, thinking about it more, I'll update the comparison logic to work both ways :)

To remove the quotes, you have to let it know that it's not a !!str but a !!timestamp. Easiest way to do that is to parse the value:

yq '.Expiration |= from_yaml'

This is effectively the same thing if you had a number in a string and wanted an actual number.

[djmcgreal-cc]

Thanks! Good to know. Are there cases where it’s important to be able to clearly control whether the comparison is done as a string, number or timestamp do you think? From: Mike Farah ***@***.***> Date: Thursday, 2 February 2023 at 02:35 To: mikefarah/yq ***@***.***> Cc: Dan McGreal ***@***.***>, Author ***@***.***> Subject: Re: [mikefarah/yq] Order matters in date time comparisons (Issue #1537) **EXTERNAL EMAIL**

…

________________________________ Actually, thinking about it more, I'll update the comparison logic to work both ways :) To remove the quotes, you have to let it know that it's not a !!str but a !!timestamp. Easiest way to do that is to parse the value: yq '.Expiration |= from_yaml' This is effectively the same thing if you had a number in a string and wanted an actual number. — Reply to this email directly, view it on GitHub<https://protect-us.mimecast.com/s/dEdtCo2PykurVLvMU1Rgpw?domain=github.com>, or unsubscribe<https://protect-us.mimecast.com/s/gFM-CpYP2lfn0NAGFDKy7O?domain=github.com>. You are receiving this because you authored the thread.Message ID: ***@***.***> This email, including attachments, contains confidential information belonging to Cambridge Consultants. It is intended for the addressee only and may only be copied or disclosed to others with permission. If you are not the intended recipient please delete the material from any computer. Emails are subject to monitoring for legal and security purposes. If this email has been sent as a personal message the company accepts no liability for the content.

[mikefarah]

Fixed in v4.31.1.

Generally yq compares against the type of the filed, so if the tag is number, is will compare as number, timestamp it will compare as that. There are now some extra smarts around time - but I think these smarts make it behave more intuitively. (IMO) it's unlikely you'd want to sort by string a timefield. That said you could still force it by providing a mismatching datetime formatting layout.