Time Zones
Putting this here, just as a fair place to maybe or maybe not be seen.
I have NO clue how to get the time zones to be accurate since the time zone is different than usual. I'm just realizing now that my time zones between NY and UT are all wrong because I never changed it. I hope that doesn't make too much of a fuss. Now in UK, and I don't want to change my account's time zone because I intend to upload pictures from NY (some that I have saved from the past few months, and some that my son insisted he would send to me while I'm away) while I'm here and I'm not sure if that'll mess with that...
I tried batch editing and selecting them all, but I think it just changed the time to the NY time zone equivalent. Or not. I wasn't really sure what it did, honestly. But it says EDT now.
In the next few days, I'm just going to put the NY equivalent, since that's the time zone my account is in, and then batch edit to change it, and hopefully it just works out and is accurate then. If not, at least I tried.
Just putting it out there, into the universe, that I am clueless, but aware of it.
תגובות
Computers creating records with local time instead of UTC is at the heart of these problems. Knowledgeable, experienced programmers know that the only real time is UTC and that time zones should only be treated as a display setting or recorded separately. Personally, I think in this day and age, this should have long been common practice in the programming community, but even Google Photos will sort 4pm Eastern time as after 3pm Pacific. Computers using local time internally constantly creates needless complications when communicating across or traveling across time zones, when transitioning to and from daylight savings, or when time zone borders are redrawn.
Working between different platforms, I kept running into issues and ending up setting everything to a GMT time zone that doesn't use daylight savings, which created mental gymnastics for reading my clock, but fixed a lot with sorting, just not everything. On my phone, despite the EXIF data on pictures only using my time zone setting, Google Photos keeps switching back and forth between using my time zone and the time zone given by the cell tower I'm connected to. I've read this is a headache for people living near the edge of time zones and in range of towers on both sides. When I recently switched my phone back to local time, a widely-used health monitoring app from a large company showed some graphs correctly, but others had events I'd recorded an hour ago as happening in the future. It's madness! UTC is so easy for a programmer to use and prevents so many problems.
I've started obscuring all my observations anyways, for a separate reason, but it's resolved this problem. I never figured out how to make it accurate but with obscured observations the time is hidden so if the time zone is wrong for an observation now, it doesn't make a difference. Which was a happy accident or side effect of deciding to obscure everything.
I thought I was just dumb for not understanding how to fix it. I used to have to manually change the time on my phone whenever switching time zones but now my phone does it automatically, so I've become even less savvy when it comes to monitoring any of it. It was frustrating when I was trying to work this out, specially, because I understand how time works so it seemed like it should've been straightforward. I just gave it up. Nobody said anything about wrong times when those observations weren't obscured anyhow so maybe people didn't care or didn't look.
For iNat, being within 24 hours seems more than adequate in most situations. Sometimes with animals, though, especially audio, it's helpful to know whether it's day, night, dusk, or dawn.
No, it's not you, it's dumb that anybody anywhere today should have to put any effort into what a programmer should have already accounted for. This is pretty simple stuff at the back end, these translations are easy for computers. When MS-DOS started using local time in time stamps, Unix for years had already been tracking time as how many seconds from midnight GMT, Jan 1, 1970 . At the time, a PC was a big jump from a Unix mainframe, it didn't know its time zone and that was simpler for those limited machines. I get the feeling, though, that this standard was made months away from from a transition of daylight savings time and if they were deciding on how to timestamp files during a transition, especially in fall, when local time goes backwards, we would not be having this conversation and maybe even the whole Y2K thing wouldn't have been quite the panic that it was. Regardless, that there are still these issues complicating things for end users decades after PCs started tracking time zones boggles my mind.
That being said, I can see why this isn't necessarily obvious unless it's taught or until complications are encountered and I sincerely appreciate all the effort volunteers have put into this amazing site.
הוספת תגובה