innreport's ConvDate

[Todd Olson]

>Alexander Bartolich <alexander.bartolich at gmx.at> writes:
>
> > daylight saving. [...]
> > However, I'm not so sure about consequences and cure of the second
> > issue.  Probably the 25th hour can be recognized by checking
>> non-sequential time stamps.
>
>Thanks, filed as ticket #90.
>
>For daylight savings time, yeah, we'd probably have to do something like
>that, and that's a mess.  The best solution would be to switch to a
>timestamp format that either included time zone information or always used
>UTC, but that's of course a big change.


I've been recently struggling to parse some syslog logs for statistics
and have been bedeviled with daylight savings
AND leap seconds,
and the fact that the log entries are not always in time sorted order
even not considering daylight savings time

I think having at least the option to run with UTC would be best


If we were trying to use and encode daylight savings
then I'd note that we can't be guarenteed (unfortunately)
that everything involved will make the transition at the
'right' time.  There for my current favorate encoding is

    YYYYMMDDXhhmmss

where X=0 for all days except the two transition days
and on thoses days X=0 before the transition
and X=1 after the transition

The point is that these encodings can be compared (as numbers or strings)
and always yeild the correct time ordering of the datetime stamps.
Even if different programs did not agree when the transition should be
in the course of the day.

EXAMPLE: for fall 2008 Nov 2

  200811020000000
  200811020001500
  200811020003000
  200811020004500
  200811020010000
  200811020011500
  200811020013000
  200811020014500
  200811020015959
  200811021010000     ( ==   200811020020000)
  200811021011500
  200811021013000
  200811021014500
  200811021020000
  200811021021500
  200811021023000
  200811021024500
  200811021030000
  ...
  200811021235959
  200811030000000
  ...

Regards,
Todd Olson
Cornell University