Future timestamps ever needed in NOKAR 5 Core?

[Thomas Sødring]

Hi,

In a way there is such a requirement in the record keeping scenario, but
not in the core. Outer layer systems (no:forsystem) have to handle it.
Imagine a case-handler has a 30 day time-limit to finish a case. So the
case arrives 29 days before summer-time at 1200.  It's due time will be
1 hour off, unless it's handled correctly.

I have always interpreted DateTime as being "whatever is the correct
time" on that day.  So in the example above, it is up to the client to
take care of the one-hour difference.

I don't think it manifests itself as a problem, because the core is an
"archive". The core should not work with relative time. I also don't
think there's anything in the API that hints at relative time either.

Following up on that a natural question could be, well is the core a
"local archive" for finalised cases or is it a "record keeping" core
that handles "live" records? Noark 4 was very much a "record keeping"
core that handles "live" records and it was difficult for it to handle
other records that didn't come under the term "sakarkiv". Noark 5 keeps
the records management nature of "sakarkiv" but also opened up to be a
"local archive" for other types of records.

There is definitely an interesting but long discussion on what this
means in terms of how the core can and should be used. Maybe something
to write a paper about :)

You raise an interesting question. Should I handle timezones properly in
the core? Instead of assuming default Oslo time. Here's a possible
scenario. The Department of Foreign Affairs interacting with embassies
around the world, maybe in distributed Noark core(s). The same with the
Armed forces! OK, probably something to be revisited later.

 - Tom

On 02/06/2017 08:36 AM, Petter Reinholdtsen wrote:
> Is there ever going to be a need for future "generic" timestamps in a
> NOARK5 archive?  Section 6.1.1.8 in the specification state that dates
> should be according to http://www.w3.org/TR/NOTE-datetime, and this note
> specifies that all time stamps including the hour of day should also
> include a numeric time zone.
>
> But to specify 12 noon two months from now, it is in general unknown
> here in Norway if the timezone for this day is timezone +01 or +02,
> because of daylight savings.  If daylight savings are introduced or
> dropped in the two month period, the timezone changes.
>
> Is this going to be a problem with the NOARK 5 API?  Are we ever going
> to need to specify relative and/or repeating times?
>