Puma gem release date displays incorrectly on RubyGems likely due to how it is built

[vkononov]

According to https://rubygems.org/gems/puma/versions/6.3.0, puma@6.3.0 was released on 2023-05-23. However, the date method for an instance of Gem::Specification returns 1980-01-01.

It looks like the problem began with version 4.3.11.

4.3.10 = 2021-10-12 00:00:00 UTC
4.3.11 = 1980-01-01 00:00:00 UTC
4.3.12 = 1980-01-01 00:00:00 UTC
5.0.0 = 2020-09-17 00:00:00 UTC
5.0.1 = 2020-09-28 00:00:00 UTC
5.0.2 = 2020-09-28 00:00:00 UTC
5.0.3 = 2020-10-26 00:00:00 UTC
5.0.4 = 2020-10-27 00:00:00 UTC
5.1.0 = 2020-11-30 00:00:00 UTC
5.1.1 = 2020-12-10 00:00:00 UTC
5.2.0 = 2021-01-27 00:00:00 UTC
5.2.1 = 2021-02-05 00:00:00 UTC
5.2.2 = 2021-03-02 00:00:00 UTC
5.3.0 = 2021-05-07 00:00:00 UTC
5.3.1 = 2021-05-11 00:00:00 UTC
5.3.2 = 2021-05-21 00:00:00 UTC
5.4.0 = 2021-07-29 00:00:00 UTC
5.5.0 = 2021-09-19 00:00:00 UTC
5.5.1 = 2021-10-12 00:00:00 UTC
5.5.2 = 2021-10-12 00:00:00 UTC
5.6.0 = 1980-01-01 00:00:00 UTC
5.6.1 = 1980-01-01 00:00:00 UTC
5.6.2 = 1980-01-01 00:00:00 UTC
5.6.4 = 1980-01-01 00:00:00 UTC
5.6.5 = 1980-01-01 00:00:00 UTC
5.6.6 = 1980-01-01 00:00:00 UTC
6.0.0 = 1980-01-01 00:00:00 UTC
6.0.1 = 1980-01-01 00:00:00 UTC
6.0.2 = 1980-01-01 00:00:00 UTC
6.1.0 = 1980-01-01 00:00:00 UTC
6.1.1 = 1980-01-01 00:00:00 UTC
6.2.0 = 1980-01-01 00:00:00 UTC
6.2.1 = 1980-01-01 00:00:00 UTC
6.2.2 = 1980-01-01 00:00:00 UTC
6.3.0 = 1980-01-01 00:00:00 UTC

How to Reproduce the Problem

I am using a Ruby 3.2.2 with rbenv on macOS 13.4.1 (22F82), but this issue persists on other versions of Ruby and Linux operating systems that I have tried.

The following script demonstrates the issue:

fetcher = Gem::SpecFetcher.fetcher
gem_dependency = Gem::Dependency.new 'puma', ">= 6.3.0"
remote_dependencies, = fetcher.spec_for_dependency gem_dependency
remote_spec, _ = remote_dependencies.first

puts remote_spec.date
# Expected Result: 2023-05-23 00:00:00 UTC
# Actual Result: 1980-01-01 00:00:00 UTC

Response from RubyGems

I've already opened an issue #6815 with RubyGems, and this was their response.

RubyGems sets the date automatically. One potential explanation is that the machine where puma releases are built has ENV["SOURCE_DATE_EPOCH"] set to that old date for some reason. That environment variable controls the date used to build the gem, so that the exact artifact pushed to rubygems.org can be built at a later time consistently.

I looked at how puma releases the gem, and I didn't spot anything out of the ordinary. I would bring this to puma upstream.

[dentarg]

I made this an discussion as I don't think it is something actionable in the Puma code base

Also probably only @nateberkopec that can shed more light on this :)

[nateberkopec]

Tried your script and it reproduces for me as well. But ENV["SOURCE_DATE_EPOCH"] is nil for me

[dentarg]

Are you sure @nateberkopec? Might be something related to Nix that does this? Did you start to use Nix after Puma 5.0?

[searls]

I recall learning from a presentation on Nix from @penguincoder last month that it tries to lock in time/date to eliminate variances in file paths and content (and therefore hashes) due to different dates and times, so hearing Nix in this context made me think "maybe that's it!"

[dentarg]

This is pretty spot on https://github.com/NixOS/nixpkgs/blob/78faafa6e6684acd1ec9770161a85d3b83caf7c5/pkgs/stdenv/generic/setup.sh#L403

[Daniel-N-Huss]

Followed up on this with RubyGems here.

Looks to me like the maintainers would prefer setting SOURCE_DATE_EPOCH on whichever machine builds the gem; so if the puma builds are leaning on Nix (or another tool that touches SOURCE_DATE_EPOCH in the background), setting it explicitly should resolve this for other releases going forward 😄

[copiousfreetime]

Apparently I duplicated this in #3198 - which has some more investigation in it.

[vkononov]

@Daniel-N-Huss This issue still persists in Puma v6.4.0.

[dentarg]

Only @nateberkopec can address this. I'm not sure if he has any intention of doing that. I guess this is how NixOS works?

[nateberkopec]

Just for clarity: I am aware this issue exists, but it is very low on my list of things to fix.

[vkononov]

Sorry, I misunderstood that the error was fixed on the next release. You're absolutely right, though - in the grand scheme of things, this is a very unimportant issue. Thanks! 😊