Comments (4)
Hi @benjamb! Thanks for this suggestion.
I intended the formatdate
function to be primarily for producing the various machine-readable-but-also-human-readable date formats defined in different IETF RFCs and other specifications.
While I can certainly see that having access to a "unix timestamp" might be useful in some situations, to me that feels like a separate function from formatdate
because it's producing a single hard-coded representation of an entire timestamp, which would be weird to combine with the other formatted parts that formatdate
works with. Also, the natural return type of this operation would be a number rather than a string.
Given that, I'd suggest creating a new function to convert a per-conventions timestamp (RFC 3339) into a Unix timestamp, rather than adding it to FormatDateFunc
.
I'm currently being quite reserved about adding new functions directly in the stdlib
package of this repository, because the scope there has already become much larger than I had originally imagined thanks to HashiCorp contributing upstream various functions that were originally written for HashiCorp Terraform. Therefore I don't think I'd want to add such a function in this repository right now, but HashiCorp has its own library of cty
functions in addition to the ones maintained in here, and so perhaps they'd be willing to accept a unix timestamp conversion function into that library instead, which HashiCorp Packer could then include.
Thanks again!
from go-cty.
@apparentlymart Thanks for the thorough response!
I agree it doesn't actually make much sense to extend formatdate
to support this, and that perhaps I should open an issue downstream instead.
With regards to the HashiCorp cty
library, that very much looks unmaintained, so that route is likely a non-starter.
from go-cty.
Hi @benjamb,
The library I linked to was created by the Packer team specifically to hold the functions that Packer uses that I declined for upstreaming in this library (due to them having some design oddities inherited from Terraform), so I expect inactivity there is more a consequence of the library currently being "done" as far as Packer is concerned, rather than because it's closed to future enhancements.
Although I do work at HashiCorp along with being the maintainer of this personal project, I don't work on Packer and so I can't speak to what the Packer team would want to include or how they would want to include it, but I would think a discussion in their main repository would probably the best place to start, and then you can hear directly from them about whether they'd be interested in such a new function and, if so, whether they'd rather have it live in the Packer codebase or in the shared functions library I linked to before.
from go-cty.
@apparentlymart Ah, that makes sense.
Yeah I've opened an issue in the packer repository for now, we'll see what happens.
from go-cty.
Related Issues (20)
- 1.11.0 causes errors with //go:generate packer-sdc mapstructure-to-hcl2 HOT 1
- hashicorp/packer-plugin-sdk incompatible with zclconf/go-cty v1.11.0 HOT 4
- TestFormatDate fails with upcoming Go 1.20 release HOT 5
- Add support for decoding into structs with a custom tag HOT 1
- Nested go struct to cty value fails HOT 1
- Proposal: JSON serialization of `cty.Path` HOT 3
- cty/json: configure (non-)HTML-escaping serialization HOT 3
- stdlib: SetProductFunc doesn't seem to handle refinements quite right HOT 2
- How to convert cty.Value of unknown type into `interface{}` HOT 2
- cty.StringVal always doubles $ in `${}` output HOT 2
- Parse string into cty type HOT 1
- cty.StringVal always doubles $ in ${} output Pt2 HOT 1
- adding jsonencode() block into a generated terraform file using golang cty HOT 2
- Encoding values with custom function (terraform provider) HOT 1
- Marshal() generate invalid JSON HOT 2
- panic with `AsString()` on result of json encoding of to_number conversion of null value HOT 4
- Some valid `Path` values cannot be applied to their source `Value` HOT 2
- Add a deepmerge function HOT 1
- `ObjectVal` or `MapVal `without `NormalizeString` HOT 6
- Some method to avoid the lexicographical order when parsing tokens HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from go-cty.