How to get your Kobo to use non-US dates

[GeoffR]

With my reader mounted on /media/KOBOeReader, in
"/media/KOBOeReader/.kobo/Kobo/Kobo eReader.conf" there is an entry:

[ApplicationPreferences]
CurrentLocale=en_US

I changed en_US to en_NZ, powered my Glo off then back on, and now it displays the date in proper NZ format DD/MM/YY instead MM/DD/YY.

See post #120 for a list of English language locales available in firmware 2.4.0.

[jackie_w]

Thanks, Geoff

Works for me too on fw 2.1.5, but I had to Power off/on again to get it to 'take'. I used CurrentLocale=en_GB for the UK. All dates are displaying as DD/MM/YYYY for me.

[PeterT]

I just hope this does not cause issues for you with the syncing of material to/from Kobo Desktop and Kobo Servers....

[davidfor]

Thanks Geoff. I had to do the restart as well.

[murg]

Originally Posted by PeterT

I just hope this does not cause issues for you with the syncing of material to/from Kobo Desktop and Kobo Servers....

I really don't use those, so it should be ok...

[murg]

Originally Posted by PeterT

I just hope this does not cause issues for you with the syncing of material to/from Kobo Desktop and Kobo Servers....

The real response should have been: I really hope that the Kobo developers aren't that stupid!

[davidfor]

I did a WiFi sync with no obvious harm after the change. But, I'll do an extra test later to make sure the reading position gets synced with my Touch.

[latepaul]

Originally Posted by murg

The real response should have been: I really hope that the Kobo developers aren't that stupid!

Why is it stupid to assume people won't go changing standard settings in hidden config files? Or that if they do they'll know that any incompatibilities are due to their own actions?

In this case it looks like changing the locale has no effect other than the desired one but I can well imagine taking advantage of some known setting for some optimization or other on the basis that you know how it was set as delivered and there's no supported way (i.e. through the menus or desktop app) to change it. Further more if and when you decide to add the ability to change that setting at a user level you'd cater for it throughout the system.

Saying that it's stupid to not cater for every random edit someone might make to a file they're not intended to change is naive at best.

[Mrs_Often]

Originally Posted by GeoffR

With my reader mounted on /media/KOBOeReader, in
"/media/KOBOeReader/.kobo/Kobo/Kobo eReader.conf" there is an entry:

[ApplicationPreferences]
CurrentLocale=en_US

I changed en_US to en_NZ, powered my Glo off then back on, and now it displays the date in proper NZ format DD/MM/YY instead MM/DD/YY.

BIG FAT PERFECT!!

Off to do this right now. Assuming it's all locale settings, so also the 24h clock

[davidfor]

Originally Posted by latepaul

Why is it stupid to assume people won't go changing standard settings in hidden config files? Or that if they do they'll know that any incompatibilities are due to their own actions?

In this case it looks like changing the locale has no effect other than the desired one but I can well imagine taking advantage of some known setting for some optimization or other on the basis that you know how it was set as delivered and there's no supported way (i.e. through the menus or desktop app) to change it. Further more if and when you decide to add the ability to change that setting at a user level you'd cater for it throughout the system.

Saying that it's stupid to not cater for every random edit someone might make to a file they're not intended to change is naive at best.

No, the stupid thing for a developer is to not treat a date as date. To use a string or some other possibly datatype that is format dependent. All modern programming languages support date and time manipulation as dates or times. Using this makes it easy to separate the display format from the internal format. Having said that, the dates are all timestamps in the database. They are actually stored as strings. But, they are stored as YYYY-MM-DDThh:mm:ssZ or YYYY-MM-DDThh:mm:ss.sss. Both are unambiguous formats.

A quick check of the database of my Glo after the sync and some reading, shows the expected timestamp values. I am happy that changing the locale is safe.

[Mrs_Often]

Okay... what country speaks English, has a dd/mm/yy date and has a 24h clock?

I tried to sneak in en_NL but it just turned Dutch on me completely.



Oh, nevermind, en_GB gives ddmmyy dates and 24h clock (hadn't expected that).

YAY I'm happy.


EDIT: I'm so happy I can't stop looking at the date and time!

[Mrs_Often]

Originally Posted by davidfor

A quick check of the database of my Glo after the sync and some reading, shows the expected timestamp values. I am happy that changing the locale is safe.

Thanks for the confirmation

[paola]

Originally Posted by GeoffR

With my reader mounted on /media/KOBOeReader, in
"/media/KOBOeReader/.kobo/Kobo/Kobo eReader.conf" there is an entry:

[ApplicationPreferences]
CurrentLocale=en_US

I changed en_US to en_NZ, powered my Glo off then back on, and now it displays the date in proper NZ format DD/MM/YY instead MM/DD/YY.

Geoff, brilliant - you know what, I actually had seen that line in my Mini, but after all the discussion here I thought it couldn't be that simple, and that all hell would break loose... well, glad you guinea pigged, and K

[DomesticExtremis]

CurrentLocale=en_GB works for me on the mini - though I needed
to add the [ApplicationPreferences] section.
Interestingly, after a reboot, there were a lot more entries in this section.
I don't know why it was absent in the first place...

Note also that this doesn't alter the date displayed on the firmware level

[latepaul]

Originally Posted by davidfor

No, the stupid thing for a developer is to not treat a date as date.

I'm not going to argue over the handling of dates - that wasn't my point and not being privy to Kobo's server-side code I have no idea how they handle it during sync-ing (if they handle it at all). My point was that this setting hasn't been exposed as a user-changeable setting. I have no problem with people changing it if it works for them.

However I do think that the usual call-the-developer-stupid game is unfair when it relates to something the user has changed which isn't supposed to be able to be changed.