4 Aug 2020 |
oliver sanders | (this is probably why Cylc uses datetime to get timestamps as you noticed the other day) | 13:59:52 |
Ronnie Dutta | Ah | 14:00:27 |
oliver sanders | Would be nice to solve #70 but I think it'll probably have to wait for another year (but in which calendar...) | 14:01:47 |
Hilary Oliver | Download image.png | 22:17:03 |
Hilary Oliver |
Cylc as LEGO: Lots of useful bits - painful when trodden on.
| 22:17:21 |
1 Sep 2020 |
| Tim P changed their display name from tpillinger to Tim P. | 10:09:03 |
| Tim P changed their display name from Tim P to Tim Pillinger. | 10:34:12 |
14 Sep 2020 |
Ronnie Dutta | There is a longstanding mistake in Isodatetime's handling of Recurrences, specifically format number one (Rn/<start_date>/<end_date> ) https://github.com/metomi/isodatetime/issues/45 | 11:18:24 |
Ronnie Dutta | The trouble is, people probably rely on this incorrect behaviour in Cylc | 11:19:25 |
Ronnie Dutta | Would fixing this behaviour be acceptable for Cylc8 and perhaps a major release of isodatetime (3.0)? | 11:21:47 |
Ronnie Dutta | cc oliver sanders | 11:24:37 |
oliver sanders | What's the motivation for fixing this now? | 12:08:09 |
Ronnie Dutta | It would make sense as part of updating isodatetime in Cylc (bringing all the hashable data classes stuff). However, will be possible to implement the update without fixing the issue, | 12:26:47 |
Ronnie Dutta | One option discussed in our catch-up meeting today was the possiblity of a prefix to the usual syntax to mark the old format | 13:38:08 |
Ronnie Dutta | * One option discussed in our catch-up meeting today was the possiblity of a prefix to the usual syntax to mark the old format going forward | 13:38:20 |
Hilary Oliver | My opinion, best to fix it, and call on the standard for back up if it pisses off anyone relying on the wrong behaviour. The alternative is to confuse new users who expect the standard to be obeyed, which is worse. | 22:11:45 |
Hilary Oliver | We can try to advertise the change, of course. | 22:12:09 |
15 Sep 2020 |
oliver sanders | Can you give us a summary of the kind of recurrences that get broken. | 08:03:43 |
Ronnie Dutta | E.g.
R5/2020-01-01/2020-01-05
A user familiar with the incorrect behaviour would expect this to mean "5 times between the two dates", so at midmight on each day. Whereas according to ISO8601 it means "5 times with a period of the difference between the two dates", so every four days at midnight, ending on Jan 17th
| 08:16:54 |
Ronnie Dutta | * E.g.
R5/2020-01-01/2020-01-05
A user familiar with the incorrect behaviour would expect this to mean "5 times beginning and ending on the two respective dates", so at midmight on the 1st, 2nd, ... 5th. Whereas according to ISO8601 it means "5 times with a period of the difference between the two dates", so every four days at midnight, ending on Jan 17th
| 08:17:58 |
oliver sanders | That's a pretty big difference! The intended behaviour could be obtained in other ways R5/2020-01-01/P1D (or something like that) though there is a certain elegance to having Isodatetime do the maths for you. | 08:35:05 |
oliver sanders | I don't know how widespread this usage is, would have to dig through our suite repositories to get a picture. | 08:35:36 |
16 Sep 2020 |
Ronnie Dutta | I've tried several different regexes and I can't actually find an instance of this format (at least in /home/h02/ or /home/h03/ ) | 09:13:17 |
Ronnie Dutta | (also the grep takes ages to run so I haven't always let it finish) | 09:13:54 |
Ronnie Dutta | The docs don't mention this format as far as I can tell | 09:19:19 |
18 Sep 2020 |
Tim P |
If adding it [flake8] there [isodatetime's setup.py] (good idea) add the tests_require to an all group so we can pip install -e .[all] as with other repos.
Shall I do that in the same PR?
| 10:31:33 |
oliver sanders | If you're happy to | 10:49:55 |
Tim P | Seems like a no-brainer | 10:50:34 |
8 Oct 2020 |
Tim P | metronnie: I've just reviewed https://github.com/metomi/isodatetime/pull/183#pullrequestreview-503919868 - I've made loads of comments, but none are actually blockers - as per my statement on approval - I think that there is a more general need to look at isodatetime tests, but I think it's low priority. | 08:39:16 |
Tim P | * metronnie: I've just reviewed https://github.com/metomi/isodatetime/pull/183#pullrequestreview-503919868 - I've made loads of comments, but none are actually blockers - as per my statement on approval - I think that there is a more general need to look at isodatetime tests, but it's very low priority. | 08:42:37 |