Gerrit and ISO 8601 timestamps

113 views
Skip to first unread message

Sven Selberg

unread,
Feb 28, 2020, 5:46:58 AM2/28/20
to Repo and Gerrit Discussion
Hi,

The fact that Gerrit doesn't use ISO 8601 (logs, REST API, ....)  has popped up in various places for me lately.
The only place that uses ISO 8601 in Gerrit is when storing comments in Note DB[1].
We are currently sooo close to ISO 8601 [2] that it doesn't make sense to me that we aren't taking the full step.

REST API:
'yyyy-mm-dd hh:mm:ss.fffffffff' -> 'yyyy-mm-ddThh:mm:ss.fffffffffZ'

/Sven

Thomas Dräbing

unread,
Feb 28, 2020, 6:10:39 AM2/28/20
to Sven Selberg, Repo and Gerrit Discussion
+1 from my side

And thanks for looking at my changes, where I started to do this for the logs [1-2]. I will adapt these changes to use ISO 8601 and move them to master as you suggested.
We should definitely use the same format in all places, IMHO.


--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/117e5e72-a33c-44a6-9cd6-b62c4805b167%40googlegroups.com.

Matthias Sohn

unread,
Feb 28, 2020, 6:13:03 AM2/28/20
to Thomas Dräbing, Sven Selberg, Repo and Gerrit Discussion
On Fri, Feb 28, 2020 at 12:10 PM Thomas Dräbing <thomas....@gmail.com> wrote:
+1 from my side

And thanks for looking at my changes, where I started to do this for the logs [1-2]. I will adapt these changes to use ISO 8601 and move them to master as you suggested.
We should definitely use the same format in all places, IMHO.

+3   ;-0) 

Edwin Kempin

unread,
Feb 28, 2020, 6:21:32 AM2/28/20
to Matthias Sohn, Thomas Dräbing, Sven Selberg, Repo and Gerrit Discussion
On Fri, Feb 28, 2020 at 12:12 PM Matthias Sohn <matthi...@gmail.com> wrote:
On Fri, Feb 28, 2020 at 12:10 PM Thomas Dräbing <thomas....@gmail.com> wrote:
+1 from my side

And thanks for looking at my changes, where I started to do this for the logs [1-2]. I will adapt these changes to use ISO 8601 and move them to master as you suggested.
We should definitely use the same format in all places, IMHO.

+3   ;-0) 


On Fri, 28 Feb 2020 at 11:47, Sven Selberg <sven.s...@axis.com> wrote:
Hi,

The fact that Gerrit doesn't use ISO 8601 (logs, REST API, ....)  has popped up in various places for me lately.
The only place that uses ISO 8601 in Gerrit is when storing comments in Note DB[1].
We are currently sooo close to ISO 8601 [2] that it doesn't make sense to me that we aren't taking the full step.

REST API:
'yyyy-mm-dd hh:mm:ss.fffffffff' -> 'yyyy-mm-ddThh:mm:ss.fffffffffZ'
The suggestion makes sense to me but I worry about backwards compatibility.
It will be a huge effort to find and fix all callers who parse timestamps that are returned from the REST API.
 

Sven Selberg

unread,
Feb 28, 2020, 7:04:52 AM2/28/20
to Repo and Gerrit Discussion


On Friday, February 28, 2020 at 12:21:32 PM UTC+1, Edwin Kempin wrote:
On Fri, Feb 28, 2020 at 12:12 PM Matthias Sohn <matthi...@gmail.com> wrote:
On Fri, Feb 28, 2020 at 12:10 PM Thomas Dräbing <thomas....@gmail.com> wrote:
+1 from my side

And thanks for looking at my changes, where I started to do this for the logs [1-2]. I will adapt these changes to use ISO 8601 and move them to master as you suggested.
We should definitely use the same format in all places, IMHO.

+3   ;-0) 

On Fri, 28 Feb 2020 at 11:47, Sven Selberg <sven....@axis.com> wrote:
Hi,

The fact that Gerrit doesn't use ISO 8601 (logs, REST API, ....)  has popped up in various places for me lately.
The only place that uses ISO 8601 in Gerrit is when storing comments in Note DB[1].
We are currently sooo close to ISO 8601 [2] that it doesn't make sense to me that we aren't taking the full step.

REST API:
'yyyy-mm-dd hh:mm:ss.fffffffff' -> 'yyyy-mm-ddThh:mm:ss.fffffffffZ'
The suggestion makes sense to me but I worry about backwards compatibility.
It will be a huge effort to find and fix all callers who parse timestamps that are returned from the REST API.

Those are valid concerns and in the best of it would have been better if we did this in v3.0.

The solution that I had in mind was:
If we have first make sure we use the same timestamp-format for all of Gerrit (REST, logs ...),  we could have the global format configurable with ISO 8601 as default.
This is perhaps the least intrusive solution since it would be documented in the release-notes and each Gerrit Admin can make their own decision on which format they
will deploy on there server(s).
They could simply configure the old format to make it seamless for their users.

Other services have mitigated similar issues by having versions of the REST API.
This wouldn't be my first choice but if this is an alternative then there are basically three paths:

* Have the new REST API at f.i. /v2/, and possibly deprecate the old REST API at a later date.
  This only pushes the problem to the future.
* Have the old REST API at f.i. /v1/
  This will still cause issues with consumers but they would only need to change the URL to fix it.
  Once the consumers have encountered the issue they are aware of it and can add the more long-term fix of fixing their timestamp parsing to their backlog for a later date.
* Let REST API version be configurable / gerrit instance
  The two previous solutions are basically also configurable since service admins would get a similar effect by using redirects.

  
 
To unsubscribe, email repo-d...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-d...@googlegroups.com.

--
--
To unsubscribe, email repo-d...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-d...@googlegroups.com.

--
--
To unsubscribe, email repo-d...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-d...@googlegroups.com.

Sven Selberg

unread,
Feb 28, 2020, 7:09:04 AM2/28/20
to Repo and Gerrit Discussion
After getting some more feedback on this suggestion, I will put together a feature-suggestion for using a global, configurable timestamp format.

Edwin Kempin

unread,
Feb 28, 2020, 8:00:03 AM2/28/20
to Sven Selberg, Repo and Gerrit Discussion
This sounds feasible to me.
 

Other services have mitigated similar issues by having versions of the REST API.
This is a topic that comes up again and again, and at one point we probably need to deal with it (but I'm not sure it needs to be now).
I expect that this will result in a major rework of our REST API, e.g. instead of solving versioning of the REST API on our own, we could migrate our API to a REST framework that already has a solution for this.
 
To unsubscribe, email repo-discuss...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/f9250569-2663-48b1-a13c-a5ac6cee380e%40googlegroups.com.

Martin Fick

unread,
Feb 28, 2020, 12:28:29 PM2/28/20
to repo-d...@googlegroups.com, Sven Selberg
On Friday, February 28, 2020 4:09:03 AM MST Sven Selberg wrote:
> After getting some more feedback on this suggestion, I will put together a
> feature-suggestion for using a global, configurable timestamp format.

Global switches generally don't help users migrate. A smoother transition
would likely be achieved by introducing new fields with the new format and
then slowly deprecating the old fields with the old formats. This approach
allows admins to run a version which supports both old and new formats at the
same time so that their users have time to migrate to the new format
incrementally after the upgrade making upgrades seemless to users,

-Martin


--
The Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation

Luca Milanesio

unread,
Feb 29, 2020, 6:57:01 AM2/29/20
to Martin Fick, Luca Milanesio, repo-d...@googlegroups.com, Sven Selberg


> On 28 Feb 2020, at 17:28, Martin Fick <mf...@codeaurora.org> wrote:
>
> On Friday, February 28, 2020 4:09:03 AM MST Sven Selberg wrote:
>> After getting some more feedback on this suggestion, I will put together a
>> feature-suggestion for using a global, configurable timestamp format.
>
> Global switches generally don't help users migrate. A smoother transition
> would likely be achieved by introducing new fields with the new format and
> then slowly deprecating the old fields with the old formats. This approach
> allows admins to run a version which supports both old and new formats at the
> same time so that their users have time to migrate to the new format
> incrementally after the upgrade making upgrades seemless to users,

+1 to that, we should also think about rolling upgrades and having the old and new field side-by-side would allow a smoother migration.

Luca.

>
> -Martin
>
>
> --
> The Qualcomm Innovation Center, Inc. is a member of Code
> Aurora Forum, hosted by The Linux Foundation
>
> --
> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/2737819.h73UhWBvaF%40mfick-lnx.

Sven Selberg

unread,
Mar 3, 2020, 3:47:05 AM3/3/20
to Repo and Gerrit Discussion


On Saturday, February 29, 2020 at 12:57:01 PM UTC+1, lucamilanesio wrote:


> On 28 Feb 2020, at 17:28, Martin Fick <mf...@codeaurora.org> wrote:
>
> On Friday, February 28, 2020 4:09:03 AM MST Sven Selberg wrote:
>> After getting some more feedback on this suggestion, I will put together a
>> feature-suggestion for using a global, configurable timestamp format.
>
> Global switches generally don't help users migrate. A smoother transition
> would likely be achieved by introducing new fields with the new format and
> then slowly deprecating the old fields with the old formats. This approach
> allows admins to run a version which supports both old and new formats at the
> same time so that their users have time to migrate to the new format
> incrementally after the upgrade making upgrades seemless to users,

+1 to that, we should also think about rolling upgrades and having the old and new field side-by-side would allow a smoother migration.

Luca.


If we can live with the duplication and extra payload to the REST responses we could go for a duplication of time-stamps:

    created: "2020-03-02 08:45:44.000000000"
    created_iso8601: "2020-03-02T09:45:44.000000000+01.00"


>
> -Martin
>
>
> --
> The Qualcomm Innovation Center, Inc. is a member of Code
> Aurora Forum, hosted by The Linux Foundation
>
> --
> --
> To unsubscribe, email repo-d...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to repo-d...@googlegroups.com.

Sven Selberg

unread,
Mar 3, 2020, 3:51:18 AM3/3/20
to Repo and Gerrit Discussion


On Tuesday, March 3, 2020 at 9:47:05 AM UTC+1, Sven Selberg wrote:


On Saturday, February 29, 2020 at 12:57:01 PM UTC+1, lucamilanesio wrote:


> On 28 Feb 2020, at 17:28, Martin Fick <mf...@codeaurora.org> wrote:
>
> On Friday, February 28, 2020 4:09:03 AM MST Sven Selberg wrote:
>> After getting some more feedback on this suggestion, I will put together a
>> feature-suggestion for using a global, configurable timestamp format.
>
> Global switches generally don't help users migrate. A smoother transition
> would likely be achieved by introducing new fields with the new format and
> then slowly deprecating the old fields with the old formats. This approach
> allows admins to run a version which supports both old and new formats at the
> same time so that their users have time to migrate to the new format
> incrementally after the upgrade making upgrades seemless to users,

+1 to that, we should also think about rolling upgrades and having the old and new field side-by-side would allow a smoother migration.

Luca.


If we can live with the duplication and extra payload to the REST responses we could go for a duplication of time-stamps:

    created: "2020-03-02 08:45:44.000000000"
    created_iso8601: "2020-03-02T09:45:44.000000000+01.00"

For the timestamps in logs it's a different matter.
We could of course change the layouts for the json logs and there add the timestamp duplication and keep the txt logs as-is, with local timestamps.

Should we go for:
* REST:
Duplication of timestamps
* LOGS:
Configurable timestamp format and/or duplication of fields in the json logs

Sven Selberg

unread,
Mar 3, 2020, 4:21:24 AM3/3/20
to Repo and Gerrit Discussion
Sorry for the spam.
Forget about fhe json logs, those are already solved by [1]

Ben Rohlfs

unread,
Mar 24, 2020, 9:55:51 AM3/24/20
to Sven Selberg, Repo and Gerrit Discussion
Hi Sven,

Thanks for the proposal. Going for standards is always worthwhile considering, and we have discussed this at today's ESC meeting.

I think we all agree that we cannot just change the format. We need to do some form of migration: versioned api, config option or duplicate fields. All three have their pros and cons, but they have all in common that they create a substantial amount of churn for a lot of people. Currently we have a hard time justifying this churn. "has popped up in various places for me lately" sounds like it is nice to have, and generally we would expect that callers of our API should be able to deal with the timestamp format that we present them with.

If you would like to continue pursuing this proposal, then we would need to get a better understanding of the impact of the change.

Sorry to turn you down for the moment.

-Ben on behalf of the ESC




--
--
To unsubscribe, email repo-discuss...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/117e5e72-a33c-44a6-9cd6-b62c4805b167%40googlegroups.com.

Sven Selberg

unread,
Mar 24, 2020, 10:54:31 AM3/24/20
to Ben Rohlfs, Repo and Gerrit Discussion

​Thanks for taking the proposal under consideration.

With Martin's suggestion for the REST API: additional field with ISO8601 format, we keep backwards compatibility with the cost of a little bit of bandwidth.

I'll see if I can't find some time soon to drum up a change for the ESC to look at.


BR

Sven

From: Ben Rohlfs <bro...@google.com>
Sent: Tuesday, March 24, 2020 2:55 PM
To: Sven Selberg
Cc: Repo and Gerrit Discussion
Subject: Re: Gerrit and ISO 8601 timestamps
 

Ben Rohlfs

unread,
Mar 24, 2020, 11:01:17 AM3/24/20
to Sven Selberg, Repo and Gerrit Discussion
We had discussed the additional field a little and had a few concerns:
- There are a lot of timestamp fields in the API, so we would add quite some "clutter".
- The name for the new fields would be pretty ugly (created_iso8601), so instead of eventually removing the original fields (created) you would probably want to get the new content into the old fields names.

If you propose a change, then please also mention why this is important to you and what the benefit is for the community at large.

-Ben

Han-Wen Nienhuys

unread,
Mar 24, 2020, 11:59:49 AM3/24/20
to Ben Rohlfs, Sven Selberg, Repo and Gerrit Discussion
On Tue, Mar 24, 2020 at 4:01 PM 'Ben Rohlfs' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:
We had discussed the additional field a little and had a few concerns:
- There are a lot of timestamp fields in the API, so we would add quite some "clutter".
- The name for the new fields would be pretty ugly (created_iso8601), so instead of eventually removing the original fields (created) you would probably want to get the new content into the old fields names.

If you propose a change, then please also mention why this is important to you and what the benefit is for the community at large.


Not an ESC member, but I also have opinions, and experience with difficult cleanups.

Adding an extra field is easy, but from the perspective of the gerrit code base, we only get benefit when we remove the old field, and that is extraordinarily difficult, because you have to find all the callers, and make them use the new field.

This sets a bad precedent, and would open the door to adding more fields for compatibility sake, which doesn't scale.

FWIW,  I think it would be much more defensible if Gerrit would also accept ISO8601-formatted timestamps on the input, but that would only solve half of your problem.


To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/CAEWS%2BaNp4jzQ81fhqWAh4jnX%2Bze3X1KN9TFHLdDBGj24734jTg%40mail.gmail.com.


--
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--

Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Sven Selberg

unread,
Mar 24, 2020, 12:28:00 PM3/24/20
to Repo and Gerrit Discussion


On Tuesday, March 24, 2020 at 4:59:49 PM UTC+1, Han-Wen Nienhuys wrote:


On Tue, Mar 24, 2020 at 4:01 PM 'Ben Rohlfs' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:
We had discussed the additional field a little and had a few concerns:
- There are a lot of timestamp fields in the API, so we would add quite some "clutter".
- The name for the new fields would be pretty ugly (created_iso8601), so instead of eventually removing the original fields (created) you would probably want to get the new content into the old fields names.

If you propose a change, then please also mention why this is important to you and what the benefit is for the community at large.


Not an ESC member, but I also have opinions, and experience with difficult cleanups.

Adding an extra field is easy, but from the perspective of the gerrit code base, we only get benefit when we remove the old field, and that is extraordinarily difficult, because you have to find all the callers, and make them use the new field.

This sets a bad precedent, and would open the door to adding more fields for compatibility sake, which doesn't scale.

FWIW,  I think it would be much more defensible if Gerrit would also accept ISO8601-formatted timestamps on the input, but that would only solve half of your problem.


I'll take all input into consideration, let's see if i can come up with a solution that is acceptable for everyone if/when I can carve out some time to look into it.
If not there's always CR-2 ;-)

/Sven
 

-Ben

To unsubscribe, email repo-...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-d...@googlegroups.com.

--
--
To unsubscribe, email repo-d...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-d...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages