bake: add unixtimestampparse function #3286

crazy-max · 2025-07-02T13:47:54Z

Adds unixtimestampparse similar to terraform unix_timestamp_parse function.

bake/hclparser/stdlib.go

sdavids · 2025-07-02T15:00:01Z

One uses SOURCE_DATE_EPOCH as follows:

$ SOURCE_DATE_EPOCH=0 docker buildx bake
$ SOURCE_DATE_EPOCH=42 docker buildx bake

Does this PR support this use case?

SOURCE_DATE_EPOCH is used to pass a fixed timestamp from the outside into the build.

—

Having this rfc3339parse function is appreciated as well …

bake/hclparser/stdlib.go

crazy-max · 2025-07-02T15:31:26Z

One uses SOURCE_DATE_EPOCH as follows:
$ SOURCE_DATE_EPOCH=0 docker buildx bake
$ SOURCE_DATE_EPOCH=42 docker buildx bake
Does this PR support this use case?

SOURCE_DATE_EPOCH is used to pass a fixed timestamp from the outside into the build.

This is already supported as a standardized environment variable

Edit: We only have docs for it in https://docs.docker.com/build/ci/github-actions/reproducible-builds/ but I think we should also have some for build and bake. Maybe in https://docs.docker.com/build/building/variables/#build-tool-configuration-variables. cc @ArthurFlag

sdavids · 2025-07-02T17:12:14Z

Maybe I was not clear enough in #3197:

$ SOURCE_DATE_EPOCH=0 docker buildx bake

labels = {
    "org.opencontainers.image.created" = "how do I get SOURCE_DATE_EPOCH as an RFC3339-formatted string here"
}

The label should look like "org.opencontainers.image.created"="1970-01-01T00:00:00.000Z" and not "org.opencontainers.image.created"="0"

crazy-max · 2025-07-13T10:22:15Z

Maybe I was not clear enough in #3197:
$ SOURCE_DATE_EPOCH=0 docker buildx bake
labels = {
    "org.opencontainers.image.created" = "how do I get SOURCE_DATE_EPOCH as an RFC3339-formatted string here"
}
The label should look like "org.opencontainers.image.created"="1970-01-01T00:00:00.000Z" and not "org.opencontainers.image.created"="0"

Pushed extra commit to add unixtimestampparse similar to terraform unix_timestamp_parse function and update examples in docs: https://github.com/crazy-max/buildx/blob/bake-rdc339parse/docs/bake-stdlib.md#-rfc3339parse

sdavids · 2025-07-13T14:20:09Z

docs/bake-stdlib.md

+* `year_day` (Number) The day of the year for the timestamp, in the range 1-365 for non-leap years, and 1-366 in leap years.
+* `day` (Number) The day of the month for the timestamp.
+* `month` (Number) The month of the year for the timestamp.
+* `month_name` (String) The name of the month for the timestamp (ex. "January").


How does this work in different locales?

january/Januar/janvier/Январь/มกราคม

Maybe not expose this attribute even if the underlying implementation supports it?

This comment also applies for weekday_name (and both in unixtimestampparse).

sdavids · 2025-07-13T14:22:18Z

bake/hclparser/stdlib.go

+			"iso_week":     cty.Number,
+		})),
+		Impl: func(args []cty.Value, retType cty.Type) (cty.Value, error) {
+			ts := args[0].AsString()


Is it possible for args to be empty?

No it would fail earlier because an arg is required for this func

sdavids · 2025-07-13T14:26:39Z

bake/hclparser/stdlib.go

+			"iso_week":     cty.Number,
+		})),
+		Impl: func(args []cty.Value, retType cty.Type) (cty.Value, error) {
+			ts, _ := args[0].AsBigFloat().Int64()


You might want to also handle the error.

You might want to also handle the error.

.Int64() does not return an error as second value but accuracy: https://pkg.go.dev/math/big#Float.Int64

See my note for the tests … someone could conceivably supply the following values -1, 0, 1.2, and "0"

sdavids · 2025-07-13T14:30:58Z

bake/hclparser/stdlib_test.go

+	require.Error(t, err)
+}
+
+func TestUnixTimestampParseFunc(t *testing.T) {


You might want to add tests for -1, 0, 1.2, and "0".

sdavids · 2025-07-13T14:33:38Z

bake/hclparser/stdlib_test.go

+
+func TestRfc3339ParseFunc(t *testing.T) {
+	fn := rfc3339ParseFunc()
+	input := cty.StringVal("2024-06-01T15:04:05Z")


You might want to add tests for "" and an syntactically incorrect timestamp.

tonistiigi · 2025-07-14T16:16:42Z

docs/bake-stdlib.md

+
+```hcl
+# docker-bake.hcl
+variable "BUILD_TIME" {


I don't think this is a convention that we would want to promote. Users should set SOURCE_DATE_EPOCH in the env as UNIX timestamp, not BUILD_TIME as string, so that bake uses the same convention as other apps.

Indeed, this was just for example purpose, renamed SOURCE_DATE_EPOCH to BUILD_TIMESTAMP.

tonistiigi · 2025-07-14T19:54:38Z

docs/bake-stdlib.md

+* `iso_year` (Number) The ISO 8601 year number.
+* `iso_week` (Number) The ISO 8601 week number.
+
+```hcl


how about

variable "SOURCE_DATE_EPOCH" { type = number default = formattimestamp("X", "2015-10-21T00:00:00Z") } target "default" { args = { SOURCE_DATE_EPOCH = SOURCE_DATE_EPOCH BUILD_TIME = formattimestamp("YYYY-MM-DD'T'00:00:00Z", SOURCE_DATE_EPOCH) } }

I'm also ok for special formatting for rfc3399 for less verbosity.

I looked at forking FormatDateFunc func as they are not willing to accept timestamp format: zclconf/go-cty#130 (comment) but there's quite a lot to fork and it might be better to be aligned so users are not confused. So that's why I opted for the terraform unix_timestamp_parse function func instead.

tonistiigi

(looks like github skipped my main review message, reposing in case it doesn't appear)

Still somewhat confused about this.

what is the use case for rfc4449parse? We would want to the SOURCE_DATE_EPOCH to be the source of truth that is picked up from env as that is the convention and that is already unix.
Is returning a big struct like these new functions do some kind of convention. Can't find anything similar from current stdlib. The current convention seems to be formatdate. If we don't want to modify formatdate to have the capability to take date as UNIX timestamp (and maybe to return it) then would it make sense to add a new function, eg. formattimestamp that is the superset of the existing function (and then hide/deprecate the previous formatdate).

Signed-off-by: CrazyMax <[email protected]>

crazy-max · 2025-08-25T13:08:19Z

(looks like github skipped my main review message, reposing in case it doesn't appear)

Still somewhat confused about this.

what is the use case for rfc4449parse? We would want to the SOURCE_DATE_EPOCH to be the source of truth that is picked up from env as that is the convention and that is already unix.

Removed rfc4449parse func and just keep unixtimestampparse one to be consistent with Terraform unix_timestamp_parse function func.

Is returning a big struct like these new functions do some kind of convention. Can't find anything similar from current stdlib. The current convention seems to be formatdate. If we don't want to modify formatdate to have the capability to take date as UNIX timestamp (and maybe to return it) then would it make sense to add a new function, eg. formattimestamp that is the superset of the existing function (and then hide/deprecate the previous formatdate).

Yes I think as follow-up we could have a formattimestamp func.

crazy-max requested review from tonistiigi and jsternberg July 2, 2025 13:47

github-actions bot assigned crazy-max Jul 2, 2025

github-actions bot added area/bake area/tests labels Jul 2, 2025

crazy-max added this to the v0.26.0 milestone Jul 2, 2025

sdavids reviewed Jul 2, 2025

View reviewed changes

bake/hclparser/stdlib.go Outdated Show resolved Hide resolved

crazy-max force-pushed the bake-rdc339parse branch from e70b98b to 7a36d1f Compare July 2, 2025 14:56

crazy-max changed the title ~~bake: add rfc339parse function~~ bake: add rfc3339parse function Jul 2, 2025

sdavids reviewed Jul 2, 2025

View reviewed changes

bake/hclparser/stdlib.go Outdated Show resolved Hide resolved

crazy-max force-pushed the bake-rdc339parse branch 2 times, most recently from 33d0ecb to ec0bb73 Compare July 3, 2025 10:35

github-actions bot added the area/docs label Jul 3, 2025

crazy-max force-pushed the bake-rdc339parse branch from ec0bb73 to 8df6fc5 Compare July 13, 2025 09:07

crazy-max changed the title ~~bake: add rfc3339parse function~~ bake: add rfc3339parse and unixtimestampparse functions Jul 13, 2025

crazy-max force-pushed the bake-rdc339parse branch from 856f62b to e4913a3 Compare July 13, 2025 10:24

sdavids reviewed Jul 13, 2025

View reviewed changes

tonistiigi reviewed Jul 14, 2025

View reviewed changes

crazy-max modified the milestones: v0.26.0, v0.27.0 Jul 15, 2025

crazy-max force-pushed the bake-rdc339parse branch from e4913a3 to 12d43b2 Compare July 15, 2025 08:54

crazy-max removed this from the v0.27.0 milestone Aug 11, 2025

bake: add unixtimestampparse function

af6bc87

Signed-off-by: CrazyMax <[email protected]>

crazy-max force-pushed the bake-rdc339parse branch from 12d43b2 to af6bc87 Compare August 25, 2025 13:03

crazy-max changed the title ~~bake: add rfc3339parse and unixtimestampparse functions~~ bake: add unixtimestampparse function Aug 25, 2025

crazy-max added this to the v0.28.0 milestone Aug 25, 2025

crazy-max requested a review from tonistiigi August 25, 2025 13:08

tonistiigi modified the milestones: v0.28.0, v0.29.0 Aug 29, 2025

bake: add unixtimestampparse function #3286

Are you sure you want to change the base?

bake: add unixtimestampparse function #3286

Conversation

crazy-max commented Jul 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

sdavids commented Jul 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

crazy-max commented Jul 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sdavids commented Jul 2, 2025

Uh oh!

crazy-max commented Jul 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sdavids Jul 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sdavids Jul 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tonistiigi left a comment

Choose a reason for hiding this comment

Uh oh!

crazy-max commented Aug 25, 2025

Uh oh!

Uh oh!

crazy-max commented Jul 2, 2025 •

edited

Loading

sdavids commented Jul 2, 2025 •

edited

Loading

crazy-max commented Jul 2, 2025 •

edited

Loading

crazy-max commented Jul 13, 2025 •

edited

Loading

sdavids Jul 13, 2025 •

edited

Loading

sdavids Jul 13, 2025 •

edited

Loading