Change in date format?

[Mihai Parparita]

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.

Mihai

[thilo.h...@gmail.com]

I observed the same. Changes like that are not very helpful when you
develop against the twitter API (like I do http://www.twibble.de)

[DeWitt Clinton]

Hi all,

Any update on this?  The python client broke because of this (unannounced?) change.  As did most clients, I suspect.

-DeWitt

[Alex Payne]

Shoot. This wasn't an intentional change. I'll try to fix this ASAP.

On 5/22/07, thilo.h...@gmail.com <thilo.h...@gmail.com> wrote:
>

--
Alex Payne
http://twitter.com/al3x

[Britt Selvitelle]

Putting in a fix for this now! Sorry guys.

--
Britt Selvitelle
Do you follow me? http://twitter.com/bs

[alexkingorg]

Twitter Tools is broken on this as well...

--Alex

http://alexking.org

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)

[Britt Selvitelle]

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?

[Mihai Parparita]

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?
>

[Cameron Kaiser]

> 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 * cka...@floodgap.com
-- Support your local hospital. Play hockey. ----------------------------------

[bear]

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?

---
bear

Build and Release Engineer
Open Source Applications Foundation (OSAF)
be...@osafoundation.org
http://www.osafoundation.org

be...@code-bear.com
http://code-bear.com

[thilo.h...@gmail.com]

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?
>

[Mihai Parparita]

This seems to be happening again.

Mihai

[Britt Selvitelle]

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

[Cameron Kaiser]

> 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 * cka...@floodgap.com

-- Either he's dead, or my watch has stopped. -- Groucho Marx -----------------

[Mihai Parparita]

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
>

[DeWitt Clinton]

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.p...@gmail.com> wrote:
>

[bear]

I also agree - pick a format and please stick with it :)

[Britt Selvitelle]

Sorry! I've reverted it back to the really true original. I'm going to send out a message with a switchover date for a new format shortly.

[alexkingorg]

It might be a good idea to start versioning the API so that these
changes can be made without breaking existing apps. For example:

http://twitter.com/statuses/user_timeline.json

would always return the old date format (when it is fixed) and changes
can be made to future versions available at URLs such as:

http://twitter.com/api/1.1/statuses/user_timeline.json

Just a suggestion, thanks for listening.

--Alex King

http://alexking.org
http://crowdfavorite.net

[DeWitt Clinton]

+1 to versioning

I think it's safe to say that Twitter has reached critical mass with
the API now. : )

-DeWitt

[Alex Payne]

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!