broken for now (doesn't work on py 2.6)

Fixes on py3 at least

First thought...

At one point very early on, the hub was only returning times as string fields direct from the db, and we had code like formatTimeLong() to help out on the client side. Later we realized what a pain that was, so we we added more return fields like creation_ts to complement creation_time, etc.

It would probably make sense to go through the places in our client code where we consume those text timestamp fields and change them to consume the corresponding *_ts field instead.

It would probably also make sense to have the formatTime and formatTime functions handle numeric timestamps as well. This would make the above change fairly straightforward.

The above would sidestep this issue for our own clients, but any other clients doing the same thing would still suffer, so we should still do something there. The original version of formatTimeLong only handled a single rigid format. The tz change we introduced should only result in some limited formats, so perhaps we can do something more manual as a fallback for 2.6?

I've resigned to solve it with datetime/time modules and used dateutil which is alredy in requires. I previously thought that we've it only in CLI, but it is in base library.

still, no need for the clients to parse dates when the hub is returning numeric timestamp fields

Yes, maybe another issue for finding all those places for 1.23?

Sure, we can separate that out

It is the same for web UI.

Created #2433

Note the cli can also hit this, so we'll continue to see users with old clients running into this when running buildinfo.

I've always considered the *_ts fields to be the preferred ones for code needing to read the dates as dates, with the *_time simply being human readable text, but still I wonder if this is an issue we need to fix on the hub for api compatibility.

I've added timestamp handling to formatting functions and replace *_time in most places. (Myabe we can add _ts fields to buildroot repo_create_event_time + retire_event_time

:thumbsup:

Maybe we can add _ts fields to buildroot repo_create_event_time + retire_event_time

I think we should look into something like that, but not for this issue. I wouldn't simply add fields with those names though. For the repos, I think we need to track:

• the event that the repo is generated from
• the time the repo was created
• the time the repo was retired

The first is decidedly an event reference, but the original field name of create_event is inaccurate.

The latter two are timestamps primarily, and could possibly not be events at all (though they could be).

So we could just add two timestamp field as you say, but the naming is confusing. We could rename things a bit to be more accurate, but we'd need to be careful about api_compatibility.

At any rate, this is way outside the scope of this issue. If we want to follow up on this, we should have a separate issue for it.

Created #2460 for that.

Commit b104e7a1 fixes this pull-request