Visit the Time.local in the macro.

[zw963]

Feature Request

Check discuss on this

Following is a example code

module College
  VERSION          = {{ `shards version "#{__DIR__}"`.chomp.stringify }}
  DEPLOYED_VERSION = {{ `git rev-parse --short HEAD`.chomp.stringify + `crystal eval 'puts Time.local.to_s(" %Y/%m/%d %H:%M:%S")'`.chomp.stringify }}
end

The output like this:

Deployed version: f5ca099 2024/06/21 18:16:48

Above time serve as a build time, deploy time, or release date for CLI app, is used for confirm we are packaged the binary or deployed the website which built on specified time.

I consider we should get the Time.local use a better way than awful crystal eval ... workaround.

[crysbot]

This issue has been mentioned on Crystal Forum. There might be relevant details there:

https://forum.crystal-lang.org/t/print-compile-time-when-app-starts/6278/16

[straight-shoota]

I don't see a reasonable use case for embedding the build time.
It can be considered an antipattern because it hinders reproducible builds.
If you really want do this, you can use the run macro. But I don't think there's a good reason to encourage this via a macro API.

[zw963]

Users have their own purposes for use Time.local in the compile time, this is a so basic function, don't expect to seek help from date crystal run or crystal eval.

[zw963]

The C language offer predefined macro __DATE__ and __TIME__ for almost same purpose, i don't know why add Time.local into macro is unacceptable.

#include <stdio.h>

int main(void) { printf("Compiled on: %s %s\n", __DATE__, __TIME__); }

$: gcc 1.c -o 1 && ./1
Compiled on: Jul 16 2024 14:43:23

I don't see a reasonable use case for embedding the build time.

@straight-shoota , can you explain why C needs to provide them?

[straight-shoota]

Most C compilers actually observe SOURCE_DATE_EPOCH for __DATE__ and __TIME__.

$: SOURCE_DATE_EPOCH=1711095856 gcc 1.c -o 1 && ./1
Compiled on: Mar 22 2024 08:24:16

That's great for reproducible builds. But it's different from what you would expect from Time.local in a macro context.

We could perhaps consider introducing some utilities for working with time (especially formatting) in macros, in order to make SOURCE_DATE_EPOCH more accessible.