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