UK/US date format in Basecamp 4.2.2

Glad to hear you're making headway.

Any info on which release a fix for this (and the Arrive / Continue problem that's driving Zumo users around the globe nuts) are likely to appear in and when?

Please see the Arrive Continue thread. This was mentioned.

And I have just committed a fix for this issue as well that should be out with the 4.2.4 release.

Please see the Arrive Continue thread. This was mentioned.

And I have just committed a fix for this issue as well that should be out with the 4.2.4 release.

I say "should" be out. It is being tested. Keep that in mind.

Thanks for that. I completely understand the caveat regarding testing.

We believe we have this under control. Please stay tuned for an update announcement. Not sure when that will be.

Whoa there, not so fast.

I just installed update 4.4.2 on 02/NOV/2014 - so whatever the previous update number was, it messed up my sync of 28/10 (US format 12h clock)... but yet bizarrely yesterdays worked fine (UK format 24h clock)

I'm wondering if this is a function of how you connect your device to the PC as it is seemingly picking up the date formats at random?

[Updating the s/w doesn't correct a date already written to file so I guess I have to edit each one but that's a minor issue.]

I attach a screendump of my most recent syc list with three USA imposters present.

...there's more

Actually, add an issue.

I wondered if I renamed a date in a filename (the list name which relates to the date/time I synced my device) if it was just a filename - no problem - or REALLY a date (and hence I wouldn't be able to change it)...

But I didn't even get that far because it came up with THIS** error - utterly bizarre since ALL these list items contain '/'!

I am beginning to consider Basecamp a kind of perpetual-Beta, or that unkind?:confused:

**

The dates and date format within BaseCamp are based on your Computer's locale settings (or should be anyway).

Can you post to me exactly what you changed in the above message so that I can replicate the behavior? Steps would be good.

Sorry I can't replicate /remember the steps right now as yesterday I did a massive reorg of my folders and deleted all the dated ones.

But if it helps, these dates (per screenshot in my first post) were the folder/list names created automagically when you click the 'fetch data from device' button... as you can see from the screen dump the dates I did this are random and infrequent, but the conditions should have been the same - same PC, no changes to settings or OS whatsoever (on my part, but then Microsoft updates might have an influence...?)

One thing I can tell you is that BC update occurred recently that changed the FORMAT of ALL the folder names (so that folders appear in chrono order when sorted) - I must have performed this update around 29/30 august since my folder names changed around then (But bizarrely not in a clean cut-off from 'old format' to 'new format' but mixed over a couple of days.)

And another clue might be that Garmin have thrown a lot of changes to device 'syncing' - (not just software updates but a whole new way of syncing). Over a period of months, even when connecting the SAME device, BC recognised it as a different device - so until recently I had THREE high level folders representing the same device. (Unfortunately I have also deleted these, sorry!)

I ran a bunch of updates a few weeks ago - updated the software - the maps - the DEVICE software...

(The admin is endless with tech! The migration from the previous 'map updater' to 'Express' nearly had me hanging from the nearest tree, I can tell you... and that was before I got anywhere near getting my maps! A case of restarting PC and connecting device several times, but I guess you know that drill.)

Anyway, you can see there are many variables here. The point is thatit is the way the device talks to BC that is the issue here.

Re: the error in screen dump no 2 above - since I deleted these folders/lists and moved the files somewhere else I can't 'prove' this. But all i did was right click > 'rename' > edit the name and as a result of the name already containing '/' it threw up the error. I don't really need to solve this 'error' - but it's bizarre that the program itself is permitted to put slash in a folder name but the user is not, doncha think? (If you try to put a slash in any folder name you can get this message too).

I hope the above helps.