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
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
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
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
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
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
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
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
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
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
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
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
I've seen a value of "18446744072363093454" for stat %Z (seconds since
epoch), for some files on a users device (Android 6.01).
This seems suspiciously large and I'm wondering what the valid range for
this value is.
What range is valid for the filesystem to return and what value range can
toybox
13 matches
Mail list logo