Date Format for JSON
Julien Genestoux
Monica Wilkinson
--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To post to this group, send email to activity...@googlegroups.com.
To unsubscribe from this group, send email to activity-strea...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.
Julien Genestoux
James Snell
Sylvain Hellegouarch
What about the timezone?
> This just came up for us too. While I generally prefer the RFC3339 format,
> until there is decent support within javascript for parsing those, epoch is
> a good fallback.
>
> On Tue, Nov 23, 2010 at 8:43 AM, Monica Wilkinson
> <monica...@gmail.com>wrote:
>
>> I second that vote because that is what we use at Socialcast and it is easy
>> to handle. Where you thinking Epoch ?
>>
>>
>> On Tue, Nov 23, 2010 at 8:33 AM, Julien Genestoux <
>> julien.g...@gmail.com> wrote:
>>
>>> Hello everyone,
>>>
>>> I've read briefly the spec and found that the prefered format for dates is
>>> supposed to be W3CDTF.
>>> I've found that it's far from trival to parse these correctly and many
>>> languages (including Javascript!) require some specific handling to parse
>>> these correctly.
>>>
>>> Would it be unreasonable to use integer timestamps?
>>>
>>> Julien
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Activity Streams" group.
>>> To post to this group, send email to activity...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/activity-streams?hl=en.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Activity Streams" group.
>> To post to this group, send email to activity...@googlegroups.com.
>> To unsubscribe from this group, send email to
Darren Bounds
> --
> You received this message because you are subscribed to the Google Groups
> "Activity Streams" group.
> To post to this group, send email to activity...@googlegroups.com.
> To unsubscribe from this group, send email to
> activity-strea...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/activity-streams?hl=en.
>
--
darren bounds
dar...@cliqset.com
Monica Wilkinson
Julien Genestoux
James Snell
Julien Genestoux
Martin Atkins
> I would recommend Epoch + GMT
>
I might argue that knowing the timezone the actor was in when the
activity was performed is useful information for interpreting the action
-- for example, checking in at a bar at lunch time probably means
something different than checking in at a bar at night.
However, with that said we never specified that the event time should be
given in the local timezone of the actor, so this was not possible before.
We might consider adding a separate optional field to encode the
timezone of the actor at the time the action was performed, although I
expect it would only be correct in very specialized cases such as
location checkins where the application is able to infer a timezone;
most applications don't have timezone information at all, and those that
do often just collect it as a per-user setting that doesn't take into
account travel.
Darren Bounds
On Tue, Nov 23, 2010 at 12:15 PM, Monica Wilkinson
--
Thank you,
Darren Bounds
John Panzer
Nick Howard
see https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/parse
Martin Atkins
>
> W3CDTF: Simple to emit, a bit more difficult to parse. Unlimited range
> of dates. Can represent sub-second timestamps with fractional seconds.
> Contains a timezone. Human (developer) readable. Required to parse
> Atom, so you'd hope there'd be libraries available already.
>
When I wrote my python reference implementation of Activity Streams
parsing I just stole the W3CDTF parsing function from the universal feed
parser, which was easy enough.
It seems like Julien and others want brainless handling of the dates in
JavaScript. Assuming no support libraries are allowed to solve this
problem, I think this leaves us with milliseconds (or fractional
seconds) since the UNIX epoch or the RFC 1123 Time Format, both with GMT
as the reference timezone. (Unix timestamps are generally handled as GMT
rather than UTC; I don't know about RFC 1123 Time.)
A naive W3CDTF parser (that isn't resilient to invalid input) isn't too
hard to implement in JavaScript with a regex, but I can sympathize with
the desire to reduce the amount of support code required given that we
generally want to send as small a payload to browsers as possible for
optimal performance.
Tatu Saloranta
> On 11/23/2010 09:19 AM, John Panzer wrote:
>>
>> W3CDTF: Simple to emit, a bit more difficult to parse. Unlimited range
>> of dates. Can represent sub-second timestamps with fractional seconds.
>> Contains a timezone. Human (developer) readable. Required to parse
>> Atom, so you'd hope there'd be libraries available already.
>>
>
> When I wrote my python reference implementation of Activity Streams parsing
> I just stole the W3CDTF parsing function from the universal feed parser,
> which was easy enough.
>
> It seems like Julien and others want brainless handling of the dates in
> JavaScript. Assuming no support libraries are allowed to solve this problem,
I am not 100% sure I agree that this is a worthy goal, however.
Javascript platform is so lacking with date handling, that one tends
to eventually always need a good date handling lib. I certainly had
to, when writing a firehose implementation 6 months back.
So while I too really like the idea of minimizing dependencies, there
are cases where it just might not be feasible.
The point about timezone is the biggest thing for me; since while this
can be added as a separate property, it will actually complicate
format, compared to having single string value with embedded
information.
-+ Tatu +-
Monica Wilkinson
Will Norris
John Panzer
I love it that "making payload smaller" is mentioned as a reason in
the same message that suggests changing the label from "updated" to
"postedTimestamp".
I don't think this is being driven by logic but by fashion at this point.
On Wednesday, January 5, 2011, Will Norris <wi...@willnorris.com> wrote:
> looks like this issue was never resolved, but the spec still mentions W3CDTF. Any hope of closing this issue?
> - will
>
> On Tue, Nov 23, 2010 at 10:02 AM, Monica Wilkinson <monica...@gmail.com> wrote:
> Agreed all developers understand Epoch so I think it would help us and we all want to keep the payload small.
> How about "postedTimestamp" ?
>
> Also I will recommend to json-schema team to support gmt-millisec as a format.
> Currently they only support utc-millisechttp://tools.ietf.org/html/draft-zyp-json-schema-03#section-5.23
--
Tantek Çelik
Agreed with Panzer's sentiment.
If you want to avoid (or minimize?) bikeshedding on name, try re-using from Atom, e.g. Probably an FAQ but what's wrong with "published" and not putting type info ("timestamp") into the field name.
Also, +1 on using ISODates, in particular W3CDTF and I'm also partial to ordinal isodates.
Re: js libs etc for handling them. It's fairly trivial.
CASSIS has functions for handling/converting ISO dates (including ordinal dates) and works great whether you call them from JS or PHP:
http://github.com/tantek/cassis
Enjoy,
Tantek
(relurk)
Danayel
remember that no matter what format is chosen, only one of us needs to
write the parser once and share it and then we can all just plug it
in. It's not like we are going to have to write it once a week.
That said, I personally am in favor of a timezoned, human readable
date - W3CDTF or RFC 3339 (which are both subsets of ISO 8601 anyway)
Why?
- Timezones are important, time is very relative and not absolute for
activites.
- If the right date format is chosen, then in many cases it may not
even have to be parsed before displaying it - the most common use of
activity data.
- It makes reading and testing output a lot easier when we can read
the raw Json without having to parse all our dates first.
- The payload change isn't really going to be that significant and
could be minimized by using a shorter tag (as mentioned above)
- They are formats already recognized by RSS and Atom aggregators so
developers are familiar with them
-D
On Jan 6, 7:29 am, "Tantek Çelik" <tan...@cs.stanford.edu> wrote:
> (unlurk)
>
> Agreed with Panzer's sentiment.
>
> If you want to avoid (or minimize?) bikeshedding on name, try re-using from Atom, e.g. Probably an FAQ but what's wrong with "published" and not putting type info ("timestamp") into the field name.
>
> Also, +1 on using ISODates, in particular W3CDTF and I'm also partial to ordinal isodates.
>
> Re: js libs etc for handling them. It's fairly trivial.
>
> CASSIS has functions for handling/converting ISO dates (including ordinal dates) and works great whether you call them from JS or PHP:
>
> http://github.com/tantek/cassis
>
> Enjoy,
>
> Tantek
>
> (relurk)
>
> -----Original Message-----
> From: John Panzer <jpan...@google.com>
> Sender: activity...@googlegroups.com
> Date: Wed, 5 Jan 2011 14:21:15
> To: activity...@googlegroups.com<activity...@googlegroups.com>
> Reply-To: activity...@googlegroups.com
> Subject: Re: Date Format for JSON
>
> Perhaps you should get Bob Wyman's input.
>
> I love it that "making payload smaller" is mentioned as a reason in
> the same message that suggests changing the label from "updated" to
> "postedTimestamp".
>
> I don't think this is being driven by logic but by fashion at this point.
>
> > looks like this issue was never resolved, but the spec still mentions W3CDTF. Any hope of closing this issue?
> > - will
>
> > Agreed all developers understand Epoch so I think it would help us and we all want to keep the payload small.
> > How about "postedTimestamp" ?
>
> > Also I will recommend to json-schema team to support gmt-millisec as a format.
> > Currently they only support utc-millisechttp://tools.ietf.org/html/draft-zyp-json-schema-03#section-5.23
>
> > If others want to syndicate other formats they can still do this but I think we should air on the simplest approach.
>
>
> > On 11/23/2010 09:19 AM, John Panzer wrote:
>
> > W3CDTF: Simple to emit, a bit more difficult to parse. Unlimited range
> > of dates. Can represent sub-second timestamps with fractional seconds.
> > Contains a timezone. Human (developer) readable. Required to parse
> > Atom, so you'd hope there'd be libraries available already.
>
> > When I wrote my python reference implementation of Activity Streams parsing I just stole the W3CDTF parsing function from the universal feed parser, which was easy enough.
>
> > It seems like Julien and others want brainless handling of the dates in JavaScript. Assuming no support libraries are allowed to solve this problem, I think this leaves us with milliseconds (or fractional seconds) since the UNIX epoch or the RFC 1123 Time Format, both with GMT as the reference timezone. (Unix timestamps are generally handled as GMT rather than UTC; I don't know about RFC 1123 Time.)
>
> > A naive W3CDTF parser (that isn't resilient to invalid input) isn't too hard to implement in JavaScript with a regex, but I can sympathize with the desire to reduce the amount of support code required given that we generally want to send as small a payload to browsers as possible for optimal performance.
>
> > --
> > You received this message because you are subscribed to the Google Groups "Activity Streams" group.
> > To post to this group, send email to activity...@googlegroups.com.
> > To unsubscribe from this group, send email to activity-strea...@googlegroups.com.
> > --
> > You received this message because you are subscribed to the Google Groups "Activity Streams" group.
> > To post to this group, send email to activity...@googlegroups.com.
> > To unsubscribe from this group, send email to activity-strea...@googlegroups.com.
> > --
> > You received this message because you are subscribed to the Google Groups "Activity Streams" group.
> > To post to this group, send email to activity...@googlegroups.com.
> > To unsubscribe from this group, send email to activity-strea...@googlegroups.com.
> --
> --
> John Panzer / Google