Is your clock right?

Mack

Mu-43 All-Pro
Joined
Jan 14, 2018
Messages
1,150
I noticed my E-M1X clock was an hour ahead. My UTC should be -8 (West Coast, CA, USA) but it showed UTC-7. I thought I set it back on the last time change in the Fall, but perhaps not. I don't use the GPS which, I believe, will set the clock correctly.

Then I checked the E-M1 Mark II and the Pen-F and both were an hour ahead too.

I don't think I forgot to change them all, but maybe I did. That or the camera's firmware has a wrong date/time change which I've seen elsewhere at times in other things.

Anyone else notice this?
 
Joined
Jun 23, 2012
Messages
1,000
Location
Malaga, Spain
Real Name
Alan Grant
I don't use the GPS which, I believe, will set the clock correctly.
I think the OI.Share app sets the clock as soon as you connect to it, even if you don't use if for GPS. I don't use GPS either, but a few times I have been confused by the clock being silently corrected when I used the app to import photos. I wish it gave a message when doing this, as sometimes I don't actually want to clock to be updated to a time zone I may be about to leave.
 

Mack

Mu-43 All-Pro
Joined
Jan 14, 2018
Messages
1,150
I think the OI.Share app sets the clock as soon as you connect to it, even if you don't use if for GPS. I don't use GPS either, but a few times I have been confused by the clock being silently corrected when I used the app to import photos. I wish it gave a message when doing this, as sometimes I don't actually want to clock to be updated to a time zone I may be about to leave.
I haven't used the OI Share app yet. Just puzzled as to why the clocks were an hour ahead - if I didn't reset them all in the Fall (Which I believe I did along with the Nikons, but dunno now.).

I noticed this as I heard the mailman come and I can almost rely on him being here at 10:35AM, and I was using the E-1X at the time and looked at its clock and it showed 11:35AM so I thought he was late - but the camera was in error and the mailman was on time. :confused-53:

Just checked my Nikons and they are all correct on time. Nikon is a also better on their UTC-time locations too along with some map displays. Had to reset all the Olympus bodies.

Maybe it is some 2020 date error or bug if others see it in Olympus. Maybe they combined the Alaska with the CA zone which Nikon shows as different, or Arizona which never changes.
 
Joined
Jun 23, 2012
Messages
1,000
Location
Malaga, Spain
Real Name
Alan Grant
I have to admit I didn't realise until now that the E-M1X has built in GPS. I think it may be the only Olympus interchangeable lens camera that has it? So maybe something specific with that camera, as the others are "dumb" in that sense, they have no way of even trying to allow for time zones.
 

archaeopteryx

Gambian sidling bush
Joined
Feb 25, 2017
Messages
1,420
Anyone else notice this?
If you're in a location with daylight savings time a simple explanation would be Nikon supporting daylight savings shifts and Olympus not. GPS may sync the time but may not sync the time zone. I don't know about OI Share but it's not uncommon for programmers thinking about time to forget about time zone handling or not to test across all the of zone possibilities. Which, in fairness, can get pretty involved and sometimes means it's a better decision not to try to change the time zone.

Except for phones, every camera I've had has required manual clock changes for daylight savings. So generally I just leave them on standard time and don't bother with switching back and forth. I know some non-ILC body firmware moves between standard and daylight automatically but don't have specifics for ILC manufacturers.

Maybe they combined the Alaska with the CA zone which Nikon shows as different.
Combining would definitely be a bug as Alaska and California are an hour apart.
 

Mack

Mu-43 All-Pro
Joined
Jan 14, 2018
Messages
1,150
If you're in a location with daylight savings time a simple explanation would be Nikon supporting daylight savings shifts and Olympus not. GPS may sync the time but may not sync the time zone. I don't know about OI Share but it's not uncommon for programmers thinking about time to forget about time zone handling or not to test across all the of zone possibilities. Which, in fairness, can get pretty involved and sometimes means it's a better decision not to try to change the time zone.

Except for phones, every camera I've had has required manual clock changes for daylight savings. So generally I just leave them on standard time and don't bother with switching back and forth. I know some non-ILC body firmware moves between standard and daylight automatically but don't have specifics for ILC manufacturers.

Combining would definitely be a bug as Alaska and California are an hour apart.
You might be right about Olympus having "Dumb Clocks" that need to be set manually for any DST changes. Why they show UTC time zones and not incorporate some DST calendar as well is baffling.

In the E-M1 Mark II manual (Page 19), and much the same for the Pen-F manual (Page 18l:
"If the battery is removed from the camera and the camera is left for a while, the date and time may be reset to the factory default setting." (Bah!)

The E-M1X manual and its GPS (Page 48):
"GPS can be used to correct the clock. Time and date information acquired via GPS are used to automatically correct the clock while the camera is on. The time zone must be selected in advance using the [Time Zone] option." *** I'll also add, You must also have the "Auto Time Adjust" turned ON in the E-M1X menu as leaving it OFF reverts the E-M1X to a "Dumb Clock."

Given I had my E-M1X GPS off, Olympus must be using the "Dumb Clock" where I needed to set it manually for any time change area. Nikon wins here, but neither of mine have a GPS in them although they seem to be programmed for DST zones and set them automatically - although they do drift a few seconds each month.
 

wjiang

Mu-43 Legend
Joined
Sep 7, 2013
Messages
7,582
Location
Christchurch, New Zealand
My clock is inevitably an hour out for DST.

GPS has it's own time base which you can convert to UTC. You won't get local time from it, ever. As for DST - it's a PITA to implement in software, as not all countries/states have the same DST start/end dates, and not all shift by a whole hour. It also changes as local laws change!
 

pigiron

Mu-43 Veteran
Joined
Feb 27, 2016
Messages
316
Location
Oregon
it's not uncommon for programmers thinking about time to forget about time zone handling or not to test across all the of zone possibilities. Which, in fairness, can get pretty involved
Indeed. One needs an up to date database to keep up as time zone date changes and reclassifications are not unknown at the margins. Countries adopt and then stop using DST after a few years. Some places have changed their timezones to the next one ahead or behind. In North America the interconnects for the Western, Eastern, and Texas power grids all use Central Standard Time throughout the year. The Indian sub-continent has zones 15, 30, and 45 minutes offset from the straight up hour of UTC. And dealing with leap seconds is always problematical for global applications.

https://www.timeanddate.com/time/map/

I got into the habit of setting my outer bezel of my watch, camera, and computer's clock to UTC. That way I can accurately back any timestamp on photos or files to the local clock at the location where they were created.

I love sundials. Now that I'm retired I set my non-date mechanical wristwatch to synch with true solar noon every morning when winding my watch. That way I can quickly identify where true north lies when in the woods. An astro photographer might very well synch to sidereal time.

If I have a doctors appointment I just use my damn phone.
 
Last edited:

barry13

Mu-43.com Editor
Joined
Mar 7, 2014
Messages
9,728
Location
Southern California
Real Name
Barry
I think the OI.Share app sets the clock as soon as you connect to it, even if you don't use if for GPS. I don't use GPS either, but a few times I have been confused by the clock being silently corrected when I used the app to import photos. I wish it gave a message when doing this, as sometimes I don't actually want to clock to be updated to a time zone I may be about to leave.
The current versions of the app have an option to turn that off.
I've thought about putting the camera on UTC, as I often forget to update the clock when traveling.
 

Growltiger

Mu-43 Hall of Famer
Joined
Mar 26, 2014
Messages
2,038
Location
UK
The current versions of the app have an option to turn that off.
I've thought about putting the camera on UTC, as I often forget to update the clock when traveling.
That is what I do. My cameras are set to UTC and never change.
 

archaeopteryx

Gambian sidling bush
Joined
Feb 25, 2017
Messages
1,420
DST - it's a PITA to implement in software
Well, kind of. The usual coding pattern is to store and manipulate everything as UTC internally and convert to or from local time only when interacting with the user by calling platform functionality such as TimeZone.ToLocalTime() and ToUniversalTime(). What sits underneath those APIs is a table of translation rules about what offsets to apply when (e.g. CurrentTimeZone.GetUtcOffsetFromUniversalTime()). As @pigiron points out, table updates are needed when the laws behind the rules change. But they don't change that often, so it's not a big maintenance cost. Particularly if someone else takes care of it.

Where I've found the bookkeeping becomes complex is coding across different timezones. Basic tracking with something like DateTimeOffset isn't a big deal but, if the code design isn't thought through carefully, it's easy to end up with bugs around when to use local time references, when to use universal time, when to compute differences between times as local times, when to compute UTC differences, when are two times with the same UTC offset from different time zones and therefore different even though they look the same, and so on. So, depending on the application, a { UTC, offset } tuple may be insufficient and { UTC, time zone } be called for.

Kind of an interesting variant of this is solar times, where at least { UTC, latitude, longitude } is needed. Doesn't come up with cameras much, though.

GPS has it's own time base which you can convert to UTC. You won't get local time from it, ever.
Well, not directly. However, from a latitude and longitude you can look up the applicable time zone and use that to compute a local time. Which can be kind of useful. But then there are cases like "@Mack just carried their E-M1X across the Utah-Arizona border during daylight savings. Do they want this code to automatically adjust the time by an hour or not?" I've also dealt with the same design problem as @alan1972 mentioned where a device's current time zone isn't relevant.

And dealing with leap seconds is always problematical for global applications.
Most implementations I know of just ignore them since it's uncommon to need that level of accuracy. I have hit bugs like "We need a date a decade in the future so just add 10 the current year and leave day and month unchanged." Works fine until the code tries to do that on February 29th.

although they do drift a few seconds each month
That's decent stability. A few seconds per month is a mean clock accuracy of around 5 ppm. Comfortably lower than the tolerance of most clock crystals found in consumer devices last I checked, though it's been narrowing over time. I have some devices that drift by tens of minutes a month and, in a clock check a few weeks ago, I found one that'd got off by over a day.
 

Mack

Mu-43 All-Pro
Joined
Jan 14, 2018
Messages
1,150
Wonder if the new E-M1 Mark III will have the internal GPS as does the E-M1X? If so, it should be able to run a decent clock DST time.

Checked my two P&S cameras: The Canon Powershot did change to the correct time (Close enough.), but the Pentax Optio is a just a dumb clock and didn't. Neither have GPS.

I would think Olympus would be able to get it close as Nikon, but maybe it is some time code software copyright held by someone for a few dollars and they didn't bite paying for it.
 

pigiron

Mu-43 Veteran
Joined
Feb 27, 2016
Messages
316
Location
Oregon
Riddle:

A guy is in Florida on a business trip. He calls his wife back home in Oregon to say goodnight. After a bit he looks at his phone and says: "OK sweetie, I've got to say goodnight because it is so'n'so o'clock and I've got to get up early tomorrow." She answers "That's the same time it is here."

How is this possible?
 

pigiron

Mu-43 Veteran
Joined
Feb 27, 2016
Messages
316
Location
Oregon
Because daylight savings shifts are asynchronous. Lots of explanations of this one. Logan 2011 was the first I clicked on with maps and tables to make it obvious.
Jeez, I was hoping for some humorous replies before you ruined it!!! :(

Looking at that map makes one wonder about the precise accuracy of any phone software that relies on cell towers to pinpoint location, especially in NE Arizona. Perhaps a Joe Leaphorn mystery could hinge on that?
 
Last edited:

wjiang

Mu-43 Legend
Joined
Sep 7, 2013
Messages
7,582
Location
Christchurch, New Zealand
Well, kind of. The usual coding pattern is to store and manipulate everything as UTC internally and convert to or from local time only when interacting with the user by calling platform functionality such as TimeZone.ToLocalTime() and ToUniversalTime(). What sits underneath those APIs is a table of translation rules about what offsets to apply when (e.g. CurrentTimeZone.GetUtcOffsetFromUniversalTime()). As @pigiron points out, table updates are needed when the laws behind the rules change. But they don't change that often, so it's not a big maintenance cost. Particularly if someone else takes care of it.
Yeah, I've used tzdata. I've worked on network systems with components in different time zones. I've also worked on platforms without tzdata, as well as platforms with no network connectivity where firmware updates are a PITA to manage. Imagine having to push out a firmware update for every tzdata change... I wouldn't expect an embedded device like a digital camera to have a reliably updated tzdata TBH.

Automatically doing it on latitude/longitude could have annoying effects while you're flying or crossing borders. You'll get a bunch of complaints. It's just not worth it to implement...
 

Growltiger

Mu-43 Hall of Famer
Joined
Mar 26, 2014
Messages
2,038
Location
UK
Can you explain this a bit more please.
You know your time zone at the moment so you can work out what UTC is, although you may need to think to get the date right.
Or simply use this link: https://time.is/UTC
That gives you the date and the time to put in all your cameras. Now you never need to worry about it again. Their clocks will drift over time so you will need to check them now and again if you want them really accurate.
 

Aushiker

Super Moderator
Joined
Sep 12, 2014
Messages
8,639
Location
Walyalup land, Western Australia
Real Name
Andrew
You know your time zone at the moment so you can work out what UTC is, although you may need to think to get the date right.
Or simply use this link: https://time.is/UTC
That gives you the date and the time to put in all your cameras. Now you never need to worry about it again. Their clocks will drift over time so you will need to check them now and again if you want them really accurate.
Ah okay, got it now. I was thinking there was some setting I couldn't find in the camera ... duh.

Thanks
 

Latest posts

Links on this page may be to our affiliates. Sales through affiliate links may benefit this site.
Mu-43 is a fan site and not associated with Olympus, Panasonic, or other manufacturers mentioned on this site.
Forum post reactions by Twemoji: https://github.com/twitter/twemoji
Copyright © 2009-2019 Amin Forums, LLC
Top Bottom