[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Pulp-list] Date and Time Feedback Requested!



On 04/15/2011 12:16 PM, Jay Dobies wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/15/2011 03:15 PM, Jason L Connor wrote:
On Fri, 2011-04-15 at 11:15 -0700, Mike McCune wrote:
On 04/15/2011 10:36 AM, Jason L Connor wrote:
Hi Everyone,

I'm personally struggling with date and time formats and timezone data
in pulp.

We're currently using 2 different formats, 1 for specifying date and
time information and 1 for reporting date and time information. I'd like
to see us unify this, and I'm looking for feedback on what is
easiest/most desired.

For reporting, we're generally using a timestamp as seconds since the
epoch as a float in the utc timezone.

For specifying date time data, we're accepting objects with the
following integer fields: (year, month, day, hour, minute) in the local
timezone of the pulp server.


This is obviously confusing... (especially because some of the reporting
is using the second format, like for repo schedules)


Here's what I'd like to propose:

The date/time format is always an object, with the fields(year, month,
day, hour, minute, second)
Please note that pulp will not honor the 'second' field when specify
times, it's only use is in reporting.

The times are always specified in the timezone local to the pulp server.

This keeps the logic on pulp as simple as possible. As well as providing
both a machine parsable and human readable format for date/time data.

Ok, fire away...

I'm not sure from your email what this really means from a Database,
REST-API and CLI impact.

Are you saying that dates will no longer be stored as a timestamp and
instead will be a custom object with YY/MM/DD mm:ss vs a timestamp and
the API's JSON will now have this set of fields?

{
    "scheduled_time": null,
    "exception": null,
    "status_path":
"/pulp/api/repositories/test2/sync/a3020f94-678b-11e0-93fd-0019d1630404/",
    "finish_time": "1302891027",
    "start_time": "1302891025",
...
}

would now become:


{
    "scheduled_time": null,
    "exception": null,
    "status_path":
"/pulp/api/repositories/test2/sync/a3020f94-678b-11e0-93fd-0019d1630404/",
    "finish_time": {
                     "day": "15",
                     "month": "Apr",
                     "year": "2011",
                     "hour": "11",
                     "minute": "10",
                     "second": "27"
                   },
    "start_time": {
                     "day": "15",
                     "month": "Apr",
                     "year": "2011",
                     "hour": "11",
                     "minute": "09",
                     "second": "14"
                   },
...
}

or something similar?

My first reaction is I prefer timestamps since it is a standard format
that all languages can parse and understand.  The complex object option
requires custom code to be written for all callers of the API which is
onerous, but I'll let you clarify before I go further...

Mike

Yep, that's the gist of it.

I'm liking the objects because it's easier to specify date times in, as
well as have some control over the granularity that pulp honors.

Objections, however, are welcome. I'm trying to get a feel for what to
use here.

As far as timezone data, we can add the timezone as a string in the
object.
{ 'year': 2011,
   'month': 4,
   'day': 15,
   'hour': 13,
   'minute': 14,
   'second': 49,
   'timezone': 'America/Denver'
}

The other benefit to objects is readability. It's much easier to just
look at the value and know what's going on than having to find something
to translate an arbitrary float.


seems like you are turning your API into a UI ... ok, perhaps that is a bit harsh ..

I can see the benefits but I'm just grumbling that I'll (and anyone else using the API) will have to write some pulp date parsing code to be able to pull apart your date object and put it back into the caller's native Date/Timestamp object.

that said, I do see where you are coming from. Passing inbound dates for things like when to schedule something puts the work on the caller to convert their human entered date into a UTC timestamp which is kinda weird too.

Hey, how about this!  Just include the timestamp on the output:

{
    "day": "15",
    "month": "Apr",
    "year": "2011",
    "hour": "11",
    "minute": "10",
    "second": "27",
    "timestamp": "1302891027"
},

I realize this is a bit of work at the API handler level because you would have todo some conversions but it would keep everyone happy.

Mike
--
Mike McCune
mmccune AT redhat.com
Red Hat Engineering       | Portland, OR
Systems Management        | 650.254.4248


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]