>> As a result, if we have a timestamp like this:
>>
>> Jan 1 2013, 7:00 PM EST
>>
>> will not be able to deal with the timezone component.
>
> And now that I've started poking at converting code like
> seconds(1), it looks like I'm going to need to solve it.
> I'm thinking that I want to
> As a result, if we have a timestamp like this:
>
> Jan 1 2013, 7:00 PM EST
>
> will not be able to deal with the timezone component.
And now that I've started poking at converting code like
seconds(1), it looks like I'm going to need to solve it.
I'm thinking that I want to add /adm/time
> Date handling on plan 9 is almost adequate today if you don't
> have to parse dates or deal with timezones, and don't do
> multithreading. Otherwise, it's difficult to get right, and
> we often don't.
I should have said -- I'm hoping to get some feedback.
The best feedback would be "I don't see
in the Tmd struct:
>vlongabs; /* seconds since Jan 1 1970, GMT */
in the description of tmtime():
> Tmtime converts the millisecond-resolution timestamp 'abs'
> into a Tm struct in the requested timezone.
the example:
> if(tmtime(&there, here
> Time zones are loaded by as name.
Extra word?
On Sat, Apr 25, 2020, at 8:54 PM, o...@eigenstate.org wrote:
> Date handling on plan 9 is almost adequate today if you don't
> have to parse dates or deal with timezones, and don't do
> multithreading. Otherwise, it's difficult to get right, and
> Just out of curiosity (I may have missed the point): since this is not
> heavily system dependent, and more user related, and for the sake of
> APE, did you consider the standard C and the POSIX interfaces?
First, the posix interfaces share inadequacies with plan 9.
They only work for local time
Hello,
On Sat, Apr 25, 2020 at 05:54:30PM -0700, o...@eigenstate.org wrote:
> Date handling on plan 9 is almost adequate today if you don't
> have to parse dates or deal with timezones, and don't do
> multithreading. Otherwise, it's difficult to get right, and
> we often don't.
>
> We've got a cr
