SOURCE_DATE_EPOCH not working as expected

[ljharb]

In https://github.com/tc39/proposal-pattern-matching, locally npm run build is now deterministic. It won't update the date until spec.emu is modified. However, PRs that do not update spec.emu - and builds on main that do not update it - still generate a date diff.

I suspect there's timezone issues here, and it's something about the value i'm passing to the env var, or, something about the modification dates locally vs in github actions, but I'm hoping the ultimate goal of a stable spec date can be achieved somehow :-)

[bakkot]

Is there a way I can see what the diff is?

[ljharb]

Whenever I've checked it, it's just been "the date" - if you mean which specific date, one way would be to add the logging to CI here: https://github.com/tc39/proposal-pattern-matching/runs/7272048687?check_suite_focus=true but another would be for ecmarkup to print out some debug info when SOURCE_DATE_EPOCH is passed.

[bakkot]

I mean that I want to see what the diff is between the files locally and in CI, yes.

[ljharb]

https://github.com/tc39/proposal-pattern-matching/runs/7273193396?check_suite_focus=true shows the diff is from July 9th to July 10th.

[bakkot]

I'm pretty sure that's because you're deriving the timestamp from the file modification time on disk, which is not preserved in git. You can use the commit timestamp instead, if you want, but you expressed reluctance in the original thread.

I'm not sure what timestamp you're actually hoping to use, here; ecmarkup will let you specify whatever timestamp you want, and I am pretty sure that if you pass it the same timestamp it will give you the same output (everything is treated as UTC), but you do have to figure out some way to give it the same timestamp across builds for the builds to be reproducible.

[ljharb]

aha, i didn't realize git didn't preserve file modification times. i'll look into that.

[ljharb]

(either way, it still seems like it'd be useful to include the complexity in ecmarkup, rather than having to repeat it in every proposal repo)

[bakkot]

I feel exactly the opposite: because it's a lot of complexity unrelated to the core job of transforming documents, it should not be included in ecmarkup.

(I dunno about "including it in every proposal repo"; I think you're the only delegate who has expressed this preference.)

[ljharb]

I'm not the only one; every proposal repo based on the template auto-generates the HTML on every push, so every repo is affected by this.

Since ecmarkup outputs a date, it does seem related to the document it generates.

[bakkot]

It is true that the date in the HTML will be set based on when the deploy job runs, but I don't think anyone else has said they consider that to be a problem. Also it's usually just going to be a short shell command (git log -1 --format=%at or =%ct), probably?), since CI runs on linux and unlike ecmarkup does not need to handle being run on non-linux platforms or outside of git repos; it's not like it's a whole script to copy around.

I agree that having a mechanism for setting the date to an explicit timestamp is in scope, which is why I added it, but I don't consider that the mechanism for deriving such a timestamp is in scope for this project.