This has been fixed. Please let me know if you ahve any problems!
Also, I think the new format that was implemented http://dev.rubyonrails.org/ticket/8399 (which caused the format to change) would make it much easier for developers to parse. What would everyone think about moving to this format in the future?
On 5/22/07, alexkingorg <alexking...@gmail.com> wrote:
Even easier to parse would be a timestamp in the form of (milli)seconds since the epoch UTC. This can be passed to the JavaScript Date constructor, and other languages have similar constructrs.
If you introduce that in another JSON property (e.g. created_at_in_seconds) then this won't have any backward compatibility issues either.
Mihai
On May 22, 4:53 pm, "Britt Selvitelle" <anotherbr...@gmail.com> wrote:
> This has been fixed. Please let me know if you ahve any problems!
> Also, I think the new format that was implementedhttp://dev.rubyonrails.org/ticket/8399(which caused the format to change) > would make it much easier for developers to parse. What would everyone think > about moving to this format in the future?
> On 5/22/07, alexkingorg <alexking...@gmail.com> wrote:
> > On May 22, 11:38 am, "DeWitt Clinton" <dew...@unto.net> wrote: > > > Hi all,
> > > Any update on this? The python client broke because of this > > (unannounced?) > > > change. As did most clients, I suspect.
> > > -DeWitt
> > > On 5/22/07, thilo.horstm...@gmail.com <thilo.horstm...@gmail.com> wrote:
> > > > I observed the same. Changes like that are not very helpful when you > > > > develop against the twitter API (like I dohttp://www.twibble.de)
> > > > On May 22, 2:09 pm, Mihai Parparita <mihai.parpar...@gmail.com> wrote: > > > > > Dates contained in the API's JSON output used to be of the form:
> > > > > Sat May 19 23:04:54 +0000 2007
> > > > > Now they are:
> > > > > 05/22/2007 03:15:23 UTC
> > > > > Is this change intentional and permanent? The XML output is still > > > > > using the old date format.
> Even easier to parse would be a timestamp in the form of > (milli)seconds since the epoch UTC. This can be passed to the > JavaScript Date constructor, and other languages have similar > constructrs.
I think this is a fine idea as well, although I vote for seconds for ctime() and allies.
-- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Support your local hospital. Play hockey. ----------------------------------
You have the full spread of languages represented in the cloud of clients that are API consumers, so it doesn't really matter what format you use to be honest :)
Keeping it in a text format that is also an ISO format helps with human readers.
The format given above is ambiguous at best because of mm/dd or dd/mm issues and lets not even get into the use of / as a date separator or if UTC is a timezone ;)
thanks!
On May 22, 4:53 pm, "Britt Selvitelle" <anotherbr...@gmail.com> wrote:
> This has been fixed. Please let me know if you ahve any problems!
> Also, I think the new format that was implementedhttp://dev.rubyonrails.org/ticket/8399(which caused the format to change) > would make it much easier for developers to parse. What would everyone think > about moving to this format in the future?
When you say the format is something like "Sat May 19 23:04:54 +0000 2007" can a client assume that it will always be in UTC? A few words in the docs on the usage and formatting of dates, times, timezones etc. in the twitter API would be helpful. I'm sure about the new format. Although easier to parse is does not comply to any standard I believe?
Another interface issue: In the Web interface a user selects the time zone in the profile. In Germany we currently have Central European Summer Time CEST, i.e. UTC +2 (or GMT +2). The date selector offers Berlin (GMT +1). Berlin is ok but GMT +1 is not. A indication of day light saving time may avoid confusion here.
On May 22, 10:53 pm, "Britt Selvitelle" <anotherbr...@gmail.com> wrote:
> This has been fixed. Please let me know if you ahve any problems!
> Also, I think the new format that was implementedhttp://dev.rubyonrails.org/ticket/8399(which caused the format to change) > would make it much easier for developers to parse. What would everyone think > about moving to this format in the future?
> On 5/22/07, alexkingorg <alexking...@gmail.com> wrote:
> > On May 22, 11:38 am, "DeWitt Clinton" <dew...@unto.net> wrote: > > > Hi all,
> > > Any update on this? The python client broke because of this > > (unannounced?) > > > change. As did most clients, I suspect.
> > > -DeWitt
> > > On 5/22/07, thilo.horstm...@gmail.com <thilo.horstm...@gmail.com> wrote:
> > > > I observed the same. Changes like that are not very helpful when you > > > > develop against the twitter API (like I dohttp://www.twibble.de)
> > > > On May 22, 2:09 pm, Mihai Parparita <mihai.parpar...@gmail.com> wrote: > > > > > Dates contained in the API's JSON output used to be of the form:
> > > > > Sat May 19 23:04:54 +0000 2007
> > > > > Now they are:
> > > > > 05/22/2007 03:15:23 UTC
> > > > > Is this change intentional and permanent? The XML output is still > > > > > using the old date format.
I've fixed this. It was a change in some of the internals, where JSON fomrats were changed from: %a %d %b %H:%M:%S %z %Y to %m/%d/%Y %H:%M:%S %Z
... for example: Sat May 19 23:04:54 +0000 2007 to 05/22/2007 03:15:23 UTC
So I've rolled back to our existing method, but it's pretty hard to parse. The new method is parsed by most languages, and fits right into JS Date objects.
So going forward, would developers rather us switch to the latter of the two formats above? I want to provide time for everyone to change their applications if you want the change to be made.
Thanks! Britt
On 6/19/07, Mihai Parparita <mihai.parpar...@gmail.com> wrote:
> I've fixed this. It was a change in some of the internals, where JSON > fomrats were changed from: > %a %d %b %H:%M:%S %z %Y > to > %m/%d/%Y %H:%M:%S %Z
> ... for example: > Sat May 19 23:04:54 +0000 2007 > to > 05/22/2007 03:15:23 UTC
> So I've rolled back to our existing method, but it's pretty hard to parse. > The new method is parsed by most languages, and fits right into JS Date > objects.
> So going forward, would developers rather us switch to the latter of the two > formats above? I want to provide time for everyone to change their > applications if you want the change to be made.
I prefer the latter, but can live with the former.
-- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Either he's dead, or my watch has stopped. -- Groucho Marx -----------------
> I've fixed this. It was a change in some of the internals, where JSON > fomrats were changed from: > %a %d %b %H:%M:%S %z %Y > to > %m/%d/%Y %H:%M:%S %Z
> ... for example: > Sat May 19 23:04:54 +0000 2007 > to > 05/22/2007 03:15:23 UTC
> So I've rolled back to our existing method, but it's pretty hard to parse. > The new method is parsed by most languages, and fits right into JS Date > objects.
> So going forward, would developers rather us switch to the latter of the two > formats above? I want to provide time for everyone to change their > applications if you want the change to be made.
> Thanks! > Britt
> On 6/19/07, Mihai Parparita <mihai.parpar...@gmail.com> wrote:
> > This seems to be happening again.
> > Mihai
> > On May 22, 8:09 am, Mihai Parparita <mihai.parpar...@gmail.com> wrote: > > > Dates contained in the API's JSON output used to be of the form:
> > > Sat May 19 23:04:54 +0000 2007
> > > Now they are:
> > > 05/22/2007 03:15:23 UTC
> > > Is this change intentional and permanent? The XML output is still > > > using the old date format.
I agree with Mihai. I think people will be fine with whichever format, as long as it stays consistent and we know well in advance of any changes.
For instance, the python library has been failing for the past day with:
ValueError: time data did not match format: data=Wed 13 Jun 20:05:15 +0000 2007 fmt=%a %b %d %H:%M:%S +0000 %Y
Since this breaks all code that uses that library, should I push out a new version with the new date format, will the server revert to the old format, or something else?
Thanks!
-DeWitt
On 6/19/07, Mihai Parparita <mihai.parpar...@gmail.com> wrote:
> As long as these changes are announced, I'm fine with either format.
> More importantly, formats are still incorrect. Now I'm seeing:
> Wed 20 Jun 03:15:24 +0000 2007
> Before the format was:
> Sun May 27 06:50:49 +0000 2007
> (note the month name and day order)
> Mihai
> On Jun 19, 9:43 pm, "Britt Selvitelle" <anotherbr...@gmail.com> wrote: > > I've fixed this. It was a change in some of the internals, where JSON > > fomrats were changed from: > > %a %d %b %H:%M:%S %z %Y > > to > > %m/%d/%Y %H:%M:%S %Z
> > ... for example: > > Sat May 19 23:04:54 +0000 2007 > > to > > 05/22/2007 03:15:23 UTC
> > So I've rolled back to our existing method, but it's pretty hard to parse. > > The new method is parsed by most languages, and fits right into JS Date > > objects.
> > So going forward, would developers rather us switch to the latter of the two > > formats above? I want to provide time for everyone to change their > > applications if you want the change to be made.
> > Thanks! > > Britt
> > On 6/19/07, Mihai Parparita <mihai.parpar...@gmail.com> wrote:
> > > This seems to be happening again.
> > > Mihai
> > > On May 22, 8:09 am, Mihai Parparita <mihai.parpar...@gmail.com> wrote: > > > > Dates contained in the API's JSON output used to be of the form:
> > > > Sat May 19 23:04:54 +0000 2007
> > > > Now they are:
> > > > 05/22/2007 03:15:23 UTC
> > > > Is this change intentional and permanent? The XML output is still > > > > using the old date format.
> I agree with Mihai. I think people will be fine with whichever > format, as long as it stays consistent and we know well in advance of > any changes.
> I also agree - pick a format and please stick with it :)
> On Jun 20, 10:29 am, "DeWitt Clinton" <dew...@unto.net> wrote: > > I agree with Mihai. I think people will be fine with whichever > > format, as long as it stays consistent and we know well in advance of > > any changes.
I'm hoping there's going to be a good opportunity for a backend revision that will warrant a new public-facing API version. Thanks for the suggestions!
On 6/20/07, DeWitt Clinton <dew...@unto.net> wrote:
