Re: [Toybox] Stat %Z - What are valid values?

2017-02-08 Thread Rob Landley
I still have this todo item: On 12/30/2016 11:28 AM, darken wrote: > I've seen a value of "18446744072363093454" for stat %Z (seconds since > epoch), for some files on a users device (Android 6.01). To which Elliot replied with: On 12/30/2016 01:39 PM, enh wrote: > time_t on 32-bit Android is

Re: [Toybox] Stat %Z - What are valid values?

2017-01-26 Thread Rob Landley
On 01/25/2017 06:25 PM, Rich Felker wrote: >> According to man 2 time: >> >> time() returns the time as the number of seconds since the Epoch, >> 1970-01-01 00:00:00 + (UTC). >> >> I.E. the definition of unix time is UTC. So %s _not_ being UTC is silly. > > Nobody is questioning

Re: [Toybox] Stat %Z - What are valid values?

2017-01-25 Thread Rich Felker
On Wed, Jan 25, 2017 at 05:15:37PM -0600, Rob Landley wrote: > On 01/24/2017 06:10 PM, Rich Felker wrote: > >>> strptime with %s? I suspect there are some nasty underspecified issues > >>> with how it interacts with timezones. > >> > >> I thought unix time was always UTS and the timezone just

Re: [Toybox] Stat %Z - What are valid values?

2017-01-25 Thread Rob Landley
On 01/24/2017 06:10 PM, Rich Felker wrote: >>> strptime with %s? I suspect there are some nasty underspecified issues >>> with how it interacts with timezones. >> >> I thought unix time was always UTS and the timezone just affected how it >> was displayed? > > The problem is that strptime

Re: [Toybox] Stat %Z - What are valid values?

2017-01-24 Thread Rich Felker
On Tue, Jan 24, 2017 at 05:47:46PM -0600, Rob Landley wrote: > > > On 01/21/2017 06:25 PM, Rich Felker wrote: > > On Sat, Jan 21, 2017 at 03:18:28PM -0600, Rob Landley wrote: > >>> Or if it's signed, that's -1346458162 which would be... sometime in the > >>> 1930's? hmmm... "./date -D %s -d

Re: [Toybox] Stat %Z - What are valid values?

2017-01-24 Thread enh
On Tue, Jan 24, 2017 at 3:47 PM, Rob Landley wrote: > > > On 01/21/2017 06:25 PM, Rich Felker wrote: >> On Sat, Jan 21, 2017 at 03:18:28PM -0600, Rob Landley wrote: Or if it's signed, that's -1346458162 which would be... sometime in the 1930's? hmmm... "./date -D %s -d

Re: [Toybox] Stat %Z - What are valid values?

2017-01-24 Thread Rob Landley
On 01/21/2017 06:25 PM, Rich Felker wrote: > On Sat, Jan 21, 2017 at 03:18:28PM -0600, Rob Landley wrote: >>> Or if it's signed, that's -1346458162 which would be... sometime in the >>> 1930's? hmmm... "./date -D %s -d -1346458162" is failing under glibc, >>> and failing _differently_ under

Re: [Toybox] Stat %Z - What are valid values?

2017-01-21 Thread Rich Felker
On Sat, Jan 21, 2017 at 03:18:28PM -0600, Rob Landley wrote: > > Or if it's signed, that's -1346458162 which would be... sometime in the > > 1930's? hmmm... "./date -D %s -d -1346458162" is failing under glibc, > > and failing _differently_ under musl. (Wheee.) > > > > /me goes down tangent

Re: [Toybox] Stat %Z - What are valid values?

2017-01-21 Thread Rob Landley
On 12/30/2016 04:01 PM, enh wrote: > On Fri, Dec 30, 2016 at 1:51 PM, Rob Landley wrote: >> On 12/30/2016 01:39 PM, enh wrote: >>> 1928-04-26 17:31:55.746667836 18446744072394174731 >> >> Really we can partially blame posix here for not specifying whether >> time_t is signed or

Re: [Toybox] Stat %Z - What are valid values?

2016-12-30 Thread Rob Landley
On 12/30/2016 01:39 PM, enh wrote: > 1928-04-26 17:31:55.746667836 18446744072394174731 Really we can partially blame posix here for not specifying whether time_t is signed or unsigned. (If it's unsigned it can't represent times before January 1, 1970, as the code on the left is doing. And there

Re: [Toybox] Stat %Z - What are valid values?

2016-12-30 Thread Rob Landley
I have negotiated a 3 day weekend for the holidays! Starting today. Ok, catching up... On 12/30/2016 01:39 PM, enh wrote: > time_t on 32-bit Android is 32 bits. > > that particular value looks like a sign-extension of 0xAFBEADCE, which > is still some time in 2063. Or if it's signed, that's

Re: [Toybox] Stat %Z - What are valid values?

2016-12-30 Thread enh
time_t on 32-bit Android is 32 bits. that particular value looks like a sign-extension of 0xAFBEADCE, which is still some time in 2063. (so i'd assume this device's clock is set wrong, and i'd assume -- since this is presumably a 32-bit device with a signed 32-bit time_t -- that that's going to