Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

filename date UTC vs localtz #48

Closed
teleshoes opened this issue Aug 30, 2015 · 9 comments
Closed

filename date UTC vs localtz #48

teleshoes opened this issue Aug 30, 2015 · 9 comments

Comments

@teleshoes
Copy link

harmattan 0.0.29-1
in tz=US/Eastern (-0400), if i take a picture after 2000, the file name is from tomorrow.

i seem to remember tz being added as a hidden config option, but i cant find it in the src. am i nuts?

@foolab
Copy link
Owner

foolab commented Aug 30, 2015

Is that because we use GMT for the date stamp? The option was never added (Or it was added and reverted).

@teleshoes
Copy link
Author

ah, i thought it used to be there, but maybe it was just talked about.
yep. an option for setting a custom static timezone instead of UTC would be perfect. (although i think using the local timezone is preferable, as long as you gently prevent collisions. maybe an option for that instead?)

EDIT: sorry for the doublepost, wrong github account

@foolab
Copy link
Owner

foolab commented Aug 30, 2015

The issue is if we use local time then we will break the naming if you travel somewhere. We can jump backwards in time or skip a whole day

@teleshoes
Copy link
Author

yes, i understand. it would be ok to just be able to set the static timezone to something other than GMT (since i spend 95% of my time in -0400).

however, i DO think using local timezone is acceptable (as a configurable option). my reasoning runs thusly: changing the timezone is like changing the system time. if you change the system time (like, if you insert a sim card after not having one in, or if you manually set it), you will also break the naming. => as long as damaging filename collisions NEVER happen, its ok for some weirdness to happen in edge cases.

@foolab
Copy link
Owner

foolab commented Aug 31, 2015

Well, you don't change the time when you change the SIM card :)

But anyway I am fine adding the feature. I will label is as an enhancement and implement it at some point.

It's not straight forward to detect collisions anymore due to how the newly introduced panorama mode works :(

@foolab
Copy link
Owner

foolab commented Aug 31, 2015

It will most likely be a hidden setting or added to a newly created advanced section. Would that work for you?

@teleshoes
Copy link
Author

yes, that would be great! hidden setting is perfectly fine with me. (advanced settings ui is a little superfluous, if users should know what theyre doing anyway.)

however, it would be preferable for the option to be 'bool use_local_time_zone' rather than 'char* time_zone_override'. (having both options would be better still).
one concern i have with the latter is daylight savings time. 'US/Eastern' is -0400 for 8months and -0500 for 4months. dunno whether youd be storing a timezone or a timezone-offset.

as for inserting the simcard, it does in fact set the time from the celltower (i dont know the mechanism, but it happens even if you dont have internet to use ntpd). even without manual intervention, drift can be several minutes in weird circumstances (or if your battery completely died or you reflashed the phone, it can change by years). my point is that relying on the local time, and NOT the local timezone, is conceptually inconsistent, and if this is all that stands in the way of file collision, its also dangerous.

speaking of collisions, thats very worrying! accidental pic deletion (either of existing pics or of the one youre about to write to file) is nearly the worst possible scenario. i THINK the phone catching on fire is worse, but maybe not always.

@foolab
Copy link
Owner

foolab commented Aug 31, 2015

I'd prefer a bool option myself and this is how I implemented it previously and reverted it afterwards. It's easier to implement and I feel storing the timezone is not the best way.
There will be collisions though (DST is an hour earlier IIRC or was it an hour later? :))

I do not like to lose user data. IMHO user data is extremely precious and I do try hard not to delete a single photo. This already works. We keep incrementing the photo counter until we find an empty slot. If we fail then we report an error to the user. The user can do nothing so he is likely to uninstall the app though :)

The issue I have with collision is the panorama mode (Not yet released). If you ask it to save the intermediate frames then it might overwrite some previous intermediate frames. I am now checking the code to see if it's only a theoretical possibility. Anyway this is not really the place for such discussion :)

P.S. Just curious: Are you using harmattan or Sailfish? I'd assume the harmattan version :)

@teleshoes
Copy link
Author

whew, all good news, thanks!
and yes, im using harmattan, at least until someone makes a phone that runs sailfish AND has north american radios.

p.s.: i am quite excited about the panorama mode, though i couldnt get it to build to test it for some reason.
p.p.s.: DST is one stupid, arbitrary hour LATER, so -0500 => -0400

@foolab foolab closed this as completed in a3a98c5 Sep 2, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants