***Error: Date in the future in changed: attribute '20070607'
Hi! I just sent a request for creating a new object in the RIPE DB, but got such error. But we really have June, 07 now here (GMT+2) =) Is it a bug or a feature? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Max Tulyev wrote:
Hi!
I just sent a request for creating a new object in the RIPE DB, but got such error.
But we really have June, 07 now here (GMT+2) =)
Is it a bug or a feature?
Dear Max This is a feature. You were trying to use the date 07 June 2007 when it was only 06 June 2007. We do not allow dates to be used in the future. That would make "changed:" attributes even less meaningful than they already are. regards Denis Walker RIPE NCC
Denis Walker wrote:
Max Tulyev wrote:
Hi!
I just sent a request for creating a new object in the RIPE DB, but got such error.
But we really have June, 07 now here (GMT+2) =)
Is it a bug or a feature?
Dear Max
This is a feature. You were trying to use the date 07 June 2007 when it was only 06 June 2007. We do not allow dates to be used in the future. That would make "changed:" attributes even less meaningful than they already are.
As Max pointed out, unless dates in the RIPE db all have to be in UTC, in his time zone it was already that date as his clock is 2 hours ahead of GMT which is 3 hours ahead of UTC at the moment. As the RIPE region also covers the regions into Israel and not to forget parts of Siberia, those people are about 6-8 hours ahead of the time in Amsterdam. Or is it a standard to always use UTC timestamps? Or is it GMT+1? Greets, Jeroen
Jeroen Massar wrote:
Denis Walker wrote:
Max Tulyev wrote:
Hi!
I just sent a request for creating a new object in the RIPE DB, but got such error.
But we really have June, 07 now here (GMT+2) =)
Is it a bug or a feature?
Dear Max
This is a feature. You were trying to use the date 07 June 2007 when it was only 06 June 2007. We do not allow dates to be used in the future. That would make "changed:" attributes even less meaningful than they already are.
As Max pointed out, unless dates in the RIPE db all have to be in UTC, in his time zone it was already that date as his clock is 2 hours ahead of GMT which is 3 hours ahead of UTC at the moment.
Another option would be to omit the date/time in the changed: and have the DB software add in what it thinks is the "appropriate" $now.
As the RIPE region also covers the regions into Israel and not to forget parts of Siberia, those people are about 6-8 hours ahead of the time in Amsterdam.
Which, imho, is a very good reason to operate all those things on UTC. Full stop.
Or is it a standard to always use UTC timestamps? Or is it GMT+1?
And DST or not? :-/
Greets, Jeroen
Wilfried.
Wilfried Woeber, UniVie/ACOnet wrote:
Jeroen Massar wrote: [..]
As Max pointed out, unless dates in the RIPE db all have to be in UTC, in his time zone it was already that date as his clock is 2 hours ahead of GMT which is 3 hours ahead of UTC at the moment.
Another option would be to omit the date/time in the changed: and have the DB software add in what it thinks is the "appropriate" $now.
Would be fine with me. Especially as 'backdated' updates can't then be made anymore. The changed line then really reflects exactly that: when it was changed.
As the RIPE region also covers the regions into Israel and not to forget parts of Siberia, those people are about 6-8 hours ahead of the time in Amsterdam.
Which, imho, is a very good reason to operate all those things on UTC. Full stop.
This is the easiest of course: clearly state it in the documentation on the site that it has to be UTC. And when rejecting it, a "times have to be UTC" notice might be appreciated.
Or is it a standard to always use UTC timestamps? Or is it GMT+1?
And DST or not? :-/
Which is why I mentioned UTC, which afaik doesn't have that crud ;) Greets, Jeroen
On Thu, Jun 07, 2007 at 01:17:47PM +0100, Jeroen Massar wrote:
As Max pointed out, unless dates in the RIPE db all have to be in UTC, in his time zone it was already that date as his clock is 2 hours ahead of GMT which is 3 hours ahead of UTC at the moment.
Another option would be to omit the date/time in the changed: and have the DB software add in what it thinks is the "appropriate" $now.
Would be fine with me. Especially as 'backdated' updates can't then be made anymore. The changed line then really reflects exactly that: when it was changed.
Jeroen, The feature is already there, if you insert a changed line without a date it will already be added: | --- | Modify SUCCEEDED: [aut-num] AS5417 | ***Warning: Date '20070508' added to changed: attribute 'marcoh@nl.demon.net' Regarding your other comment on backdating changes, keep in mind that a lot of people actually keep a list of changed attributes in an object to have some history of when people made changes. So you must be able to insert changed attributes with a date in the past. Changing that would mean people have to find a new way to maintain history or the database should get intelligent enough to copy history from the old object before replacing it. MarcoH
Marco Hogewoning wrote: [..]
| --- | Modify SUCCEEDED: [aut-num] AS5417 | ***Warning: Date '20070508' added to changed: attribute 'marcoh@nl.demon.net'
Thanks. I didn't know about that handy feature ;)
Regarding your other comment on backdating changes, keep in mind that a lot of people actually keep a list of changed attributes in an object to have some history of when people made changes.
Yes, but that is why the last changed line of each object that is being updated (when it actually does change) can be adjusted to the correct date. This preserves any previous changed lines that are still in the object. Greets, Jeroen
Marco Hogewoning wrote: [...]
Regarding your other comment on backdating changes, keep in mind that a lot of people actually keep a list of changed attributes in an object to have some history of when people made changes.
Which indeed is essential, as I was finding out recently. Loosing or removing old changed: lines really gets some pieces of software in the NCC mixed up. You'll only find out when applying for additional address space. At least the *oldest* one should always be preserved.
So you must be able to insert changed attributes with a date in the past. Changing that would mean people have to find a new way to maintain history or the database should get intelligent enough to copy history from the old object before replacing it.
MarcoH
Wilfried.
participants (5)
-
Denis Walker -
Jeroen Massar -
Marco Hogewoning -
Max Tulyev -
Wilfried Woeber, UniVie/ACOnet