[Pulp-list] Date and Time Feedback Requested!

[Jay Dobies]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/15/2011 02:15 PM, 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...

This is definitely one side effect of it. Currently the APIs are a mix
of the two.

start_time, finish_time, last_sync are timestamps
next_sync is a dict like you described above

So part of this initiative will be to settle on one.

> Mike
> 
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list


- -- 
Jay Dobies
RHCE# 805008743336126
Freenode: jdob
http://pulpproject.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNqI9sAAoJEOMmcTqOSQHCiDgH/jN24qzsrlE+qw3drPGSLpno
zKMoL2EjPsa3+uQZbeFXV3UMR/OtZKpoVPLzkrSpH0knh/H1tmSYWkNszh8X6CJK
9XUGUw+GW0bko1jZe6Ule0B5RtwOCBxjATqxCuIhBjnjrDrqbIt2TAH597k7BbLg
0SeL3DqQ9xp0lApV2Ll/udNWN7Xl9XrzXVAvZ85o/m7gw8GpEjXWe2IhDb/5zu4K
9P/Co/YWSUcPV+dywUaKePmoGztpqhajLjTdItR3uY2IqU1aD3HaedLnASFPDdGL
f7xS0XV7WWWM9VhmvXscjoPkwRLI+E498/2mGfEQ30f92NMJlpWQru3mUxlE7Ec=
=41Mg
-----END PGP SIGNATURE-----