General XMetaL Discussion
tonys May 12, 2012 at 2:03 am
Time zone changed in change tracking markersMay 12, 2012 at 2:03 amParticipants 8Replies 9Last Activity 10 years, 4 months ago
When I make any changes to a document that contains change tracking PIs I've noticed that the times all get changed to my time zone instead of that of the original author.
As a results, the times are incorrect – but the real problem is all of these show up as differences if I compare the before and after files. I've attached a small sample.
Has anyone else noticed this, and is there a way to prevent it?tonys May 12, 2012 at 4:34 am
Reply to: Time zone changed in change tracking markersMay 12, 2012 at 4:34 am
Forgot to say: I'm using Author Enterprise version 7.0.0.093 on 64-bit Windows 7.Derek Read May 16, 2012 at 6:14 pm
Reply to: Time zone changed in change tracking markersMay 16, 2012 at 6:14 pm
This is not something new (if you are thinking that this feature has been altered for the 7.0 release). The time codes for change tracking have always been adjusted to the current time zone of the person working on the file when a document is opened. This allows the times to show consistently for the current user. This way all changes are presented to you in your own time.
If you examine the time and time zone in the XML after adjustment (after the file has been opened into either Tags On or Normal view) you will see that the hours are adjusted along with the GMT offset. So in your case the GMT is changing from -0600 to +1000 and the hours are then also changed from 03 to 19.
There is no way to alter this behaviour. If you would like to make a feature request along those lines the best way to do that would be through XMetaL Support. They would need a complete description of how you expect the feature to function, and ideally the reasoning for it as well. The main thing I think you need to think about is that if these values are not adjusted what time would you want to display when you hover over a change? Your local time (ie: adjust the time 'on the fly')? The local time for the other user (no adjustment)? Both?
Perhaps you don't use the feature like our other clients do. It sounds like you have some external system set up that might be working on the XML source in some automated fashion, in which case you might not care about the user interface?tonys May 17, 2012 at 8:17 am
Reply to: Time zone changed in change tracking markersMay 17, 2012 at 8:17 am
I don't know how I missed that the time had been changed as well – guess I was just seeing what I expected to see. I also didn't notice that the change is made as soon as the file is opened.
It's a shame that this means any change can make all of the PIs for unrelated changed different. If you're putting the XML in a revision control system the significant changes can get lost in the noise.
It would be much better if the data was left unchanged, and the “hover” text converted to the current time zone.Derek Read May 17, 2012 at 11:18 pm
Reply to: Time zone changed in change tracking markersMay 17, 2012 at 11:18 pm
We've got lots of clients using Content Management Systems and this has never come up as far as I recall (and our feature request system turns up nothing either).
Can you let me know where you store your files (product name) and what particular issues this causes so I can pass that along to development?tonys May 18, 2012 at 5:14 am
Reply to: Time zone changed in change tracking markersMay 18, 2012 at 5:14 am
In this case I'm just storing the files in subversion.
Nothing actually goes wrong, it's just that a single “real” change could result in dozens of “false” changes, because the PI's have been altered.
This isn't a huge problem; I'll just stop using change tracking so no one gets confused about what has actually changed.Derek Read May 18, 2012 at 8:50 pm
Reply to: Time zone changed in change tracking markersMay 18, 2012 at 8:50 pm
I see. Does this mean you use the “merge” feature in SVN?
Perhaps the alternative would be to ask that no two people work on the same file at the same time?
Most CMS systems don't do merging because they don't let the same file be worked on by multiple people. You check a file out and nobody else can touch it until you check it back in. Maybe that's why it hasn't come up.tonys May 18, 2012 at 9:40 pm
Reply to: Time zone changed in change tracking markersMay 18, 2012 at 9:40 pm
This doesn't really have anything to do with SVN. I only reason I mentioned it was because using it to compare two versions of the file was what showed me that XMetaL had made unexpected changes to the file.
All I am suggesting is that XMetaL should not change the PI's when it reads the file. If the only reason this is done is to show the local time when hovering over the change, then surely this transform could be done “on the fly”. This would have two advantages:
Derek Read May 18, 2012 at 10:00 pm
- the modified file would only have the changes the author actually made
- the original timezone information in the change tracking would not be lost
Reply to: Time zone changed in change tracking markersMay 18, 2012 at 10:00 pm
I'll put in a feature request.
I doubt we would want to make this the default though, since there may be customizations (using APIs that interact with these values) or integrations with 3rd party systems that would expect the feature to function as it always has (we try to always be backward compatible).
I could see adding an INI setting or something that would change this. It's an old feature that's been there since somewhere between 1.0 and 2.0 I think (a little bit before my time) and there might actually be a reason for it that would require digging into the code to figure out.Derek Read May 18, 2012 at 10:16 pm
Reply to: Time zone changed in change tracking markersMay 18, 2012 at 10:16 pm
Might be interesting to note that the earliest record for this feature I can find in our bug tracker is from 1999. The XMetaL version is listed as 1.0.3, so the feature has probably been in existence since before XMetaL existed (likely inherited from a similar feature in HoTMetaL). It is a feature request related to some APIs so there's the potential for customizations that are 10+ years old to be affected here.
That's not to say that we wouldn't implement an optional setting at some point, just want to give you an idea that because we always strive for backward compatibility there are lots of things we need to be aware of when we make changes like this.
- You must be logged in to reply to this topic.