Parsing and unparsing leads to 1h time shift?

[lindig]

I assume I'm doing something wrong here but I am baffled by this behaviour:

utop # ISO8601.Permissive.datetime_tz "2020-02-14T06:56:42Z";;
- : float * float option = (1581667002., Some 0.)

utop # ISO8601.Permissive.datetime_tz "2020-02-14T06:56:42Z" |> fst |> ISO8601.Permissive.string_of_datetime;;
- : string = "2020-02-14T07:56:42"

The time printed is shifted by one hour from the time that was parsed. How would I prevent that?

[lindig]

The timestamp 1581667002 refers to Friday, 14 February 2020 07:56:42 GMT+00:00. So it appears to me that the unparsing (printing) is correct but that the parsing of 2020-02-14T06:56:42Z = 1581667002 is not correct.

[c-cube]

Is that on master? I think on master there's some changes to make it correct in #5 which has been rebased, but it caused a (small) regression in toml. Could you try on #5?

[lindig]

This was not on master but on 0.2.6. I'll try on master.

[lindig]

I believe this happens on master as well. Running the tests on master (on macOS) I also see a test failure:

:ISO8601.ml $ make test
Done: 48/50 (jobs: 1).........................................................F...
==============================================================================
Failure: ISO8601:2:[UTILS]:1:[UTILS mkdate]:4:583804800.

expected: 583804800. but got: 583808400.
------------------------------------------------------------------------------
Ran: 61 tests in: 0.04 seconds.
FAILED: Cases: 61 Tried: 61 Errors: 0 Failures: 1 Skip:  0 Todo: 0 Timeouts: 0.
ISO8601_TEST alias tests/runtest (exit 1)

I tried to use the branch from #5 but it is quite out of date (using ocamlbuild). So far did not try it.

[c-cube]

Ah my bad, what about wip-merge-pr-5 (which is the rebase of #5)?

[lindig]

On branch wip-merge-pr-5 the issue no longer exists. Running make test I see some test failures.

utop # ISO8601.Permissive.datetime_tz "2020-02-14T06:56:42Z" |> fst |> ISO8601.Permissive.string_of_datetime;;
- : string = "2020-02-14T06:56:42"

[c-cube]

Interesting, I don't see a test error on my end. I'd like to merge this at some point but am not confident enough in its correctness. Frankly, help would be very appreciated.

[undu]

Tests only work for me on branch wip-merge-pr-5 when adding --profile=release to dune runtest

[lindig]

This looks suspicious (on master):

src/ISO8601_lexer.mll:    let offset = fst (Unix.mktime (Unix.gmtime 0. )) 

This computes an offset from the date of the epoch and applies it. For me this is

utop # 
fst (Unix.mktime (Unix.gmtime 0.));;
- : float = -3600.

I don't understand what it tries to do.

[c-cube]

well, me neither. I think it's different on #5 ?

[undu]

What's the timezone of your system set to?

val mktime : tm -> float * tm

Convert a date and time, specified by the tm argument, into a time in seconds, as returned by Unix.time. The tm_isdst, tm_wday and tm_yday fields of tm are ignored. Also return a normalized copy of the given tm record, with the tm_wday, tm_yday, and tm_isdst fields recomputed from the other fields, and the other fields normalized (so that, e.g., 40 October is changed into 9 November). The tm argument is interpreted in the local time zone.

[lindig]

: tmp $ timedatectl 
               Local time: Thu 2020-02-20 17:02:47 GMT
           Universal time: Thu 2020-02-20 17:02:47 UTC
                 RTC time: Thu 2020-02-20 17:02:47
                Time zone: Europe/London (GMT, +0000)
System clock synchronized: yes
              NTP service: inactive
          RTC in local TZ: no

[undu]

the Stdlib does a system call, don't see anything egregious at first sight.

[sagotch]

mktime is interpreted in local timezone, so this is meant to compute the offset between local timezone and UTC, and suppress this offset from the given date in order to get the UTC time.

On my computer, I am at GMT+1, do I have to add 3600 seconds to get the correct UTC time from mktime.

$ timedatectl
               Local time: Fri 2020-02-21 09:32:22 CET
           Universal time: Fri 2020-02-21 08:32:22 UTC
                 RTC time: Fri 2020-02-21 08:32:22
                Time zone: Europe/Paris (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

utop # fst (Unix.mktime (Unix.gmtime 0.));;
- : float = -3600.

EDIT: In #5, I see that it has been removed. It would be nice to test the library in different time zones. It might give good results in UK but false ones in other places.
https://github.com/ocaml-community/ISO8601.ml/pull/5/files#diff-4c4ab45718b4810726f53bea3f21b0a9R6

[lindig]

As you will have noticed, I'm in GMT/UTC and still get the same -3600 offset.