Open knobo opened 8 years ago
Not sure whether this can be simplified, but it should work:
(apply #'encode-timestamp
`(,@(subseq (multiple-value-list
(decode-timestamp (parse-timestring "2016-12-01")
:timezone +utc-zone+))
0 7)
:timezone ,(find-timezone-by-location-name "America/Aruba")))
(utc
here ensures that decode-timestamp
returns the original parts of the timestamp, since parse-timesting
assumes UTC.)
This is simpler:
(apply #'encode-timestamp
`(,@(substitute 0 nil (reverse (subseq (split-timestring "2016-12-01") 0 7)))
:timezone ,(find-timezone-by-location-name "America/Aruba")))
The workaround I came up with, is
(local-time:parse-timestring "2024-09-01" :offset (local-time::subzone-offset (local-time::%subzone-as-of tz nil nil)))
which I'm not sure is much better. It relies on private interfaces.
But now the round trip (parse-timestring ...)
to (format-timeststring ... :timezone tz)
for date inputs of the form YYYY-MM-DD is consistent.
I did not know about this issue, nor pull request #58 before discovering that; I haven't looked into the details of what it does.
How can I parse a date at a timezone and get back a timestamp in local-time The date "2016-12-01" in 'America/Aruba' would be at "2016-12-01T05:00:00+01" in norway.
I can not just use the
:offset
inparse-timestring
because I don't know if it is daylight savings time or not before after the date is parsed.To explain with an example: In postgresql I do this: