On 2023-02-18 at 03:04:12, demerphq wrote: > I could understand this position if letting the user set the --mtime > implied some harm that must be mitigated, but it seems like an odd > choice if there is none. Especially given it would also future proof > git against people coming up with a good reason not to use the 0 epoch > in the future that you haven't thought of right now. It is not like > epoch's and unix time have a totally uncontroversial and stable > history. 0 has meant multiple dates over time, and the current > definition of 1 Jan 1970, 00:00:00 UTC is problematic as UTC didn't > exist until 1972! Given it clearly wouldn't be hard to allow users to > select the epoch in these archives then why not do so? If folks want such an option, they're welcome to send a patch to do that. My approach is providing a stable tar format that doesn't change, and for people who want to use that format, it has fixed timestamps for trees (so it's completely rigid). If people want to use the default format with an arbitrary timestamp, that's fine, and we can support that, but we won't guarantee that that format won't change its serialization in the future. > I have seen devs have issues with stuff like this in the past. > Unpacking an archive on one machine showing a different date than one > another, or other weird artifacts. Mac used to use a different 0 epoch > than windows and linux as I recall, etc etc. I dont remember the gory > details, but i have definitely seen people gnash their teeth over > these kind of decisions before. Why not side-step that if you can and > let people choose their own defaults? The ustar format is defined by POSIX and uses the Unix epoch, just like the zip format has its own epoch. If you're processing a tar archive, you need to use the Unix epoch. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
