Time format changed to UTC/Z in the 1.2.10 Release
Closed this issue · 6 comments
Thunderbird 60.9.1, macOS 10.15
Thanks for writing Thunderlink, it's become an indispensable part of my workflow.
The previous version replaced with "dd/mm/yyyy - hh:mm:ss" in my local time zone, per the display in Thunderbird. Release 1.2.10 now uses a format yyyy-mm-ddThh:mm:ss.sssZ which looks to be the ISO format in UTC/Z and it isn't really all that helpful.
I looked in the Thunderlink prefs pane, but couldn't see any new settings for locale or time zone. So I'm guessing the time format change was inadvertently made in the source code? Could local time formatting, preferably the same as the previous version for consistency, please be restored?
Hi there! You can always revert with a direct install I think, here's the last version https://github.com/mikehardy/thunderlink/releases/download/1.2.9/thunderlink-1.2.9-tb.xpi
What changed though?
Try 1.2.11 XPI from the release I just cut - should work with replacement tag 'localeTime' being the string you had before https://github.com/mikehardy/thunderlink/releases/tag/v1.2.11
Thanks, that restores the previous formatting for me. Much appreciated!
@mikehardy OK, I realise this Issue is closed, but I've just read #49 and I'm going to suggest here and there that the <time> format established in previous versions be restored and, instead of a new <localeTime> tag to restore the previous behaviour, a new <ISOtime> tag be created instead.
@jamesquilty I understand that you have a problem with changing behaviour.
So you are suggesting the following:
<ISOtime>should write ISO8601 time of day (format hh:mm:ss.sss)<date>should write ISO8601 date (format YYYY-MM-DD)<dateTime>should write full ISO8601<time>local time
If that is your proposal, we will use <time> for local time, and <ISOtime> for just hours, minutes ... This is strange to me. It has a semantic mismatch in tags and I don't think this is the correct way to go.
Can you please explain why is a problem for you to change your preferences to use <localTime> instead of <time>? Maybe we can find some other solution to your troubles.
I will not merge any further requests on this @jamesquilty sorry - the original one was an unmarked breaking change, which is unfortunate but already happened.
As such people have likely already reacted to it.
The second change (your requested functionality restoration) was non-breaking on purpose so that any people that already reacted were not further perturbed
That was on purpose
It is not ideal but there is no ideal once an unexpected breaking change goes out
I am not going to spend any more time on it. Go forth and conquer your todo list :-), as will I