Johannes Schindelin <johannes.schinde...@gmx.de> writes:
> Hold on. Have you tried to build this branch?
>
> -- snip --
> CC date.o
> date.c:63:36: error: unknown type name ‘timestamp_t’
> static struct tm *time_to_tm_local(timestamp_t time)
> ^
> date.c: In function ‘show_date’:
> date.c:211:8: error: implicit declaration of function ‘time_to_tm_local’
> [-Werror=implicit-function-declaration]
> tm = time_to_tm_local(time);
> ^
> date.c:211:6: error: assignment makes pointer from integer without a cast
> [-Werror=int-conversion]
> tm = time_to_tm_local(time);
> ^
> cc1: all warnings being treated as errors
> -- snap --
>
> I would expect this to be rebased *at least* to dddbad728c9 (timestamp_t:
> a new data type for timestamps, 2017-04-26).
Thanks for noticing.
My preference is to use ulong in the commit at the tip by Peff. We
can do s/ulong/timestamp_t/ in a merge that merges the topic to
newer integration branches that have the timestamp_t topic merged
(e.g. 'master'), as that allows older integration branches
(e.g. 'maint') to have the %z/%Z fix independently.
It would be another valid approach to fork it at b15667bb ("Merge
branch 'js/larger-timestamps'", 2017-05-16) or a commit that appears
later than that one on 'master', and tweak Peff's commit to use
timestamp_t, if we declare that the %z/%Z fix will only be in 2.14
and later and will never go to 'maint'.
