[Question] Days counting across DST in Gostradamus

[wakatara]

Ran across your library after a user pointed out a strange daylight savings time bug in my app harsh.

Largely, because Golang's time.Time() and addDate() punts on the days construct across DST and no-DST, so I was wondering if you'd puzzled out a way to count days properly between DST days in Gostradamus.

As an example, in my app the fact I am using AddDate(0, 0, -1) across the DST boundary causes a bug if a user tries to look at the date range between 1am and 2am BST only. ( I am gathering this occures, since when it counts backwards daily, the day BST kicks in does not have that hour actually existing -- as I'm gathering after digging into the issue and some golang bug reports on this issue).

But really, what I really want is a simple way to count iso dates that a local user experiences. so even across DST.

Does Gostradamus handle day math "properly" across DSTs for adding and subtracting days.

Had to ask since I noticed you said it is using the underlying go time library. =]

[bykof]

Hey @wakatara ,

what you probably search for is: https://github.com/bykof/gostradamus/blob/3c1d5ed924c59007914bb683e1775d00d80d64cf/datetime.go#L269

The function ShiftDays use DateTimeFromTime(dt.Time().AddDate(0, 0, days)) so exactly how you use it. AFAIK DST is part of a timezone. I am from Germany and we used CET (Central European Time) a few weeks ago. On 27th march the timezone changed to CEST (Central European Summer Time) which is a DST.

As I see timezone in Britain is BST and GMT. I am sorry, but I don't get your bug. Could you please describe a little bit more how you coded it and what is working falsy?

Best Regards Michael

[wakatara]

Sorry, if I did not explain it well. Basically day counts are off by one if I use time.Time() and addDate(0,0,-1) to count days across a DST date and a non-DST date (but only if I make the count at the time the clock would have shifted forward in that time zone for DST - in the case of the UK - 1am - 2am). Here in Singapore we have no DST... =]

A user filed the bug. It was invisible to me and quite the edge case. https://github.com/wakatara/harsh/issues/17

So, what I"m wondering is, since your library deals with dates in what seems like a better way, does it do those counts correctly even though it is uses time.Time() underneath the hood?

[wakatara]

My plan is if you have a means to day count which can evaporate the bug I'm experiencing, I was just going to reimplment with your library. =]

[bykof]

I tested it right now with Go playground and i experienced the correct behaviour Link:

package main

import (
    "fmt"
    "github.com/bykof/gostradamus"
)

func main() {
    dateTime := gostradamus.NewDateTime(2022, 3, 28, 2, 0, 0, 0, gostradamus.EuropeBerlin)
    fmt.Println(dateTime.Format("DD.MM.YYYY HH:mm:ss"))
    dateTime = dateTime.ShiftDays(-1)
    fmt.Println(dateTime.Format("DD.MM.YYYY HH:mm:ss"))
}

The output is:

28.03.2022 02:00:00
27.03.2022 03:00:00

Which is totally correct, because the 27th march does not have 02:00:00 as time, because it's switching from NoDST to DST.

Did I understand your problem correctly?