Timestreamlib does not handle timezones

[Joelgranados]

The date formats do not specify timezones. this becomes ambiguous when dealing with timestamps and the generated files will change depending on the locale. If we somehow specify timezones, we should be able to avoid this.

[kdm9]

This is semi-deliberate. We have no source of date-time info other than the images themselves, which contain no timezone info. Therefore, a design decision was made to respect the camera's time, assuming local solar time (solar time being timezone ignoring daylight savings, e.g. +10 for us, year round).

This make it easier to manage the cameras (dont' have to change time unless you physically move to a new tz), and the retrieval of time is all self contained (i.e. comes from the images themselves, with no extra input). To support timezones would require more info from the user.

To reiterate: NO code should rely on the place of execution having the same timezone as the images. Instead, never use gmtime or friends (or their python wrappers). If we just use plain, vanilla datetime objects / use struct tm & the python equivalent, then we should be ok. Let me know of any specific cases where this is not true (by reopening this bug).

[Joelgranados]

Sorry for the short bug report, I now realize that I missed specifying the specific situation.

We have two issues: a. When rereading timestamps the actual time will change. look at first part of comment 3 in https://github.com/borevitzlab/timestreamlib/issues/90. This change will be avoided if we have timezone information.

b. When rereading the timestamps in other locals, the time will change. Notice that it will be the same local time, but with a different UTC offset. This means that If I create results with my European local, you will not be able to use them compare them with results created in Australia (Unless you address the time offset).

This should be added to the TimeStream class.

[kdm9]

Don't use timestamp formats that require the location or OS of the computer to have the same timezone as the images

datetime.datetime doesn't require this, with tzinfo=None (the default). You can do the following anywhere:

strdte = "2012_12_22_16_46_59""
dtm = datetime.datetime.strptime(strdte, "%Y_%m_%d_%H_%M_%S")
assert(strdte == dtm.strftime("%Y_%m_%d_%H_%M_%S"))
# arbitrary manipulation of dte may happen, and the time zone will never shift so long as localtime is never involved

ONCE AND FOR ALL: THE ONLY TIME ZONE RECOGNISED IS THE SOLAR TIME (no DST) OF THE LOCATION THE IMAGE WAS TAKEN.

This is important, as we have no reliable source of time zone, and we can't just guess this stuff. Asking the user isn't an option, as this may lead to errors if the cameras are set to a different timezone

[Joelgranados]

a. This bug is not occurring because we use different timestamps. This bug is regarding the solar time format. b. This bug is not regarding only python, It touches on the relation of R, Matlab and python. So your example just shows part of the issue.

Execute this code in R and you will see my point:

one = as.POSIXct("2012_12_22_16_46_59", format="%Y_%m_%d_%H_%M_%S")
Sys.setenv(TZ='America/Los_Angeles')
two = as.POSIXct("2012_12_22_16_46_59", format="%Y_%m_%d_%H_%M_%S")
one == two

In my system the comparison at the end is FALSE. Its false because of the timezones. So you cannot use timestreamlib in two different timezones. This is a bug, That comparison should be TRUE for any time zone.

[kdm9]

(a) OK, sorry for the confusion (b) Yep, I see and agree with your point. However, with respect to the R code, I'm not sure why it should work exactly as you have it, but this should (and does, for me at least) work:

Sys.setenv(TZ='America/Los_Angeles')
one = as.POSIXct("2012_12_22_16_46_59", format="%Y_%m_%d_%H_%M_%S")
two = as.POSIXct("2012_12_22_16_46_59", format="%Y_%m_%d_%H_%M_%S")
one == two
Sys.setenv(TZ='Australia/Sydney')
one = as.POSIXct("2012_12_22_16_46_59", format="%Y_%m_%d_%H_%M_%S")
two = as.POSIXct("2012_12_22_16_46_59", format="%Y_%m_%d_%H_%M_%S")
one == two

What use case is your code above a simplification of?

[Joelgranados]

Yes, if the two scientists are in the same timezone there would be no problem. But if they are in different places, looking at the same data in R, they will get different times. If then each of them has results calculated by R, there will be conflicts when they put them together; they wont be able to compare them without first identifying the problem and then addressing it with extra code.

IMO, this is not a pressing matter, It could be left for when it becomes more relevant, but it needs to stay active.

[kdm9]

Really? Won't that be just do what was in my post above?

Lets let this fester until it's actually an issue.