Page MenuHomeFreeBSD

date: attempt to more accurately describe year limitations with -v
ClosedPublic

Authored by kevans on May 31 2022, 4:31 AM.
Tags
None
Referenced Files
F103868266: D35360.diff
Sat, Nov 30, 11:53 AM
Unknown Object (File)
Oct 13 2024, 11:06 PM
Unknown Object (File)
Sep 28 2024, 11:00 AM
Unknown Object (File)
Sep 18 2024, 2:56 PM
Unknown Object (File)
Sep 18 2024, 5:26 AM
Unknown Object (File)
Sep 6 2024, 1:15 AM
Unknown Object (File)
Sep 5 2024, 10:48 AM
Unknown Object (File)
Sep 2 2024, 12:35 PM

Details

Summary

The previous description was both incorrect and incomplete in its
description -- the 2038 limit doesn't apply on !i386 platforms, and
it didn't note that values above 100 are accepted and interpreted
differently. Further, it didn't note that absolute years are accepted.

Sponsored by: Klara, Inc.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 45782
Build 42670: arc lint + arc unit

Event Timeline

pauamma_gundo.com added inline comments.
bin/date/date.1
232

Just to confirm: other 32-bit architectures (ARM, MIPS, PowerPC) have the extended year range that I assume means time_t is 64 bits long?

233–234
235–236
237

Do you mean "in the 4-digit or longer year format"? If you do:

  • I'd move "absolute" to the second "year".
  • How does date decide whether 1905 means Gregorian year 1905 (absolute) or Gregorian year 1900 + 1905 = 3805 (relative to 1900)? Since 1905 is greater than 100, both interpretations are compatible with the language of your draft change.
This revision now requires changes to proceed.May 31 2022, 5:14 AM
bin/date/date.1
232

Correct, i386 is the only supported platform with a 32-bit time_t

237

4-digits are interpreted as a relative year up to and including the start of the tm_year, which is 1900 -- after that, it's just 'the desired year'. i.e., '1900y' is always 1900+1900, '1901y' and later are always the year specified.

kevans marked 5 inline comments as done.

Address review feedback (sorry for the delay)

No worry. I'm swamped anyway.

This revision is now accepted and ready to land.Jun 9 2022, 11:37 PM