PRS-505: Clock always 1 hour ahead

[sherman]

Basically as the title says, I have the modified firmware loaded onto my PRS-505, which gives me a (potentially) useful means of telling the time.

Whenever I connect my reader to my PC (Windows Vista 32-bit) the clock updates itself. The problem is that when it updates the clock, it is ALWAYS updated so that it is exactly 1 hour AHEAD of local time. Eg: if my PC clock is 1:02pm, the PRS-505 clock is 2:02pm.
Now obviously I can go and manually change the clock on my PRS, but this only lasts untill the next time I connect the reader to my PC...

Does anyone know if there is anything I can do to get the correct time on my reader when it's connected to the PC?

Thanks

(I know it's not the end of the world.. but it's the sort of thing that bugs the hell out of me...)

[ShineOn]

Originally Posted by sherman

Basically as the title says, I have the modified firmware loaded onto my PRS-505, which gives me a (potentially) useful means of telling the time.

Whenever I connect my reader to my PC (Windows Vista 32-bit) the clock updates itself. The problem is that when it updates the clock, it is ALWAYS updated so that it is exactly 1 hour AHEAD of local time. Eg: if my PC clock is 1:02pm, the PRS-505 clock is 2:02pm.
Now obviously I can go and manually change the clock on my PRS, but this only lasts untill the next time I connect the reader to my PC...

Does anyone know if there is anything I can do to get the correct time on my reader when it's connected to the PC?

Thanks

(I know it's not the end of the world.. but it's the sort of thing that bugs the hell out of me...)

Ohh, that's problem I have too. I never solved it...
What time zone have you selected in your PC? ... I have GTM-4 (Santiago)

Somebody can help?

[Valloric]

Originally Posted by sherman

Whenever I connect my reader to my PC (Windows Vista 32-bit) the clock updates itself. The problem is that when it updates the clock, it is ALWAYS updated so that it is exactly 1 hour AHEAD of local time.

I have experienced this myself, but only two times so far, not every time I connect it to the PC.

[pilotbob]

Originally Posted by sherman

Whenever I connect my reader to my PC (Windows Vista 32-bit) the clock updates itself. The problem is that when it updates the clock, it is ALWAYS updated so that it is exactly 1 hour AHEAD of local time. Eg: if my PC clock is 1:02pm, the PRS-505 clock is 2:02pm.

Do you have your PC set to automatically adjust for daylight savings? If so, try turning that off and setting your clock forward one hour manually. Although it seems that this would cause your clock to be one hour behind if the setting software isn't adjusting the clock setting for savings time.

BOb

[sherman]

Ok, that's weird, turning off DST and manually putting my clock forward (on the PC) made my reader update to the correct time. Of course that messes up my PC time and time sync to the MS time servers, so I'd rather not have this as a permanent solution.

What time zone have you selected in your PC? ... I have GTM-4 (Santiago)

We are GMT +12 here in New Zealand, although due to daylight savings, it is currently GMT +13. Which means that currently the reader clock is updated to GMT +14 if DST is turned on at my PC...

[pilotbob]

Originally Posted by sherman

Ok, that's weird, turning off DST and manually putting my clock forward (on the PC) made my reader update to the correct time. Of course that messes up my PC time and time sync to the MS time servers, so I'd rather not have this as a permanent solution.

I'm just guess here. But, Windows DST setting adjusts the time that it displays to the user but the RTC clock in the PC is still set to standard time. I'm guessing the driver gets the time from the OS, which returns the DST time, then sees that it is savings time based on date so it sets the time forward one hour.

RTC: 09:00 AM
Windows: 10:00 AM
DST is True.
Reader: 11:00 AM

Driver says... ok, Windows reports 11:00 AM and "adjust for DST" so it says ok, I'll add an hour to 11:00AM... the dev on this must not have realized that Windows reports the DST time to it rather than the ST.

So, when you turn DST adjust off... the real time clock and windows report the same time, the driver that sets the clock sees "Savings Adjust" is off so it just uses the Windows reported time which is the same as the RTC.

Once again, all guess work. The driver (or whatever sets the clock) should just use the time reported by the OS.

BOb

[sherman]

Ah well, thanks for that.

*mutters darkly under breath at Sony's programmers*

[dordale]

I'm not sure...I haven't had the problem with my reader being an hour off, but I do have daylight time adjust turn on...

dordale

[Valloric]

Actually, I think it's the problem with different DST regimes around the world. The Reader is probably designed to expect the device to be used in the US, and a user in a different country with a different DST convention will run into difficulties, that is, one hour differences.

[igorsk]

At my former company we once had an unexplainable crash in our program which was happening only at a single installation in New Zealand. No matter how we tried we could not reproduce it locally, but the client was pretty important so eventually we had to endure painful speeds of their internet and debug remotely. It's a long story how we managed to localize the problem (I still can barely beleive we did it), but, as you can guess it turned out to be the timezone. NZ is in the UTC+12 timezone, but when the DST is in effect that becomes UTC+13. Well, the library from Adobe we used was checking the timezone offset for some reason and when it got anything over 12 it sort of went "you gotta be shitting me!" and somehow that took down the whole application.

[sherman]

Originally Posted by igorsk

At my former company we once had an unexplainable crash in our program which was happening only at a single installation in New Zealand. No matter how we tried we could not reproduce it locally, but the client was pretty important so eventually we had to endure painful speeds of their internet and debug remotely. It's a long story how we managed to localize the problem (I still can barely beleive we did it), but, as you can guess it turned out to be the timezone. NZ is in the UTC+12 timezone, but when the DST is in effect that becomes UTC+13. Well, the library from Adobe we used was checking the timezone offset for some reason and when it got anything over 12 it sort of went "you gotta be shitting me!" and somehow that took down the whole application.

Whoa!!!
Well, my problem isn't quite as drastic as that thank goodness!

BTW, out of sheer curiosity, how long ago and what type of 'net connection did your client have at the time? (International bandwidth is EXPENSIVE here in NZ - courtesy of one source of intl b/w (the southern cross cable)...

[igorsk]

Oh hey, I completely missed that you're in New Zealand. That certainly makes it more probable the issue is indeed NZ's 12/13-hour timezone offset.
My story happened last year I beleive and I have no idea what connection they had, sorry...

[sherman]

Originally Posted by igorsk

Oh hey, I completely missed that you're in New Zealand. That certainly makes it more probable the issue is indeed NZ's 12/13-hour timezone offset.
My story happened last year I beleive and I have no idea what connection they had, sorry...

Ah well, doesn't matter. Depending on where they were at in the country, they could have had anything from a Citylink connection to a wireless connection or anything in between...

Sherman wishes HE had access to a citylink connection, as he types this on his ADSL connection. On a Saturday, when everyone else is also using precious international bandwidth.

EDIT: Damn, just realised I'm starting to get majorly OT here...