Ok, having backed off and gotten just a little bit of perspective on this, I think a major re-think is in order.
It hasn't escaped my attention that out of about 6.5 billion people, exactly two have expressed interest in using this program ... and one of them wants another time system. Cheerfully ignoring the first and most significant part of that, I think I've again been thinking too "small". Keep in mind that I threw the first version of this (the macro) together in my spare time over two days- a few hours- for my own use, and just to put Internet Time in journal titles, nothing else. It's already become a great deal more generic (thanks to Eric's suggestions), and I can see that if there's ANY demand for this, it's probably going to be to make it more generic. So.... here's what I now have in mind: ONE program. I'm rapidly becoming convinced that I don't want to maintain more than one in parallel for this. I've already chucked the "newJournalPlusSIT" macro. Time to chuck "InternetTimePlugin". Maybe "AlternateDateTimePlugin"? Still support the "@bbb.bb" format for Swatch Internet Time display. Support the "NETDEGMINSEC" format (or whatever it turns out to be) for NET display. That leaves the (current) "@" delimiters, used in the prototype to return date/time in arbitrary TW formats for Biel, Switzerland, to match the "@bbb.bb" display (combining local date and either NET or SIT in a display without making it very clear is a VERY bad idea). Chuck it now, while nobody's using it. I'm thinking, replace that syntax with "[UTC] [/UTC] delimiters, or optionally something like "[UTC+1]" (for, say, Biel) or "[UTC+5], in case someone just wants to display time in another time zone instead of in another system. So, "[UTC]" goes with NET time, and "[UTC+1]" goes with Internet Time, and "[UTC+5]" gives you EST. And here's where we can get a little cute.... I am NOT maintaining tables of what every politician in the world thinks that local time should be (as in, "Daylight Savings Time"), sorry. Plus, the time changes on a Sunday- you can't even do it with a date calculation. However, the Date object in Javascript does return local time by default, and can be coaxed into returning the delta between that and UTC. I don't know web stuff at all, but I assume that the Javascript engine has to be getting that from the OS that the browser is running on, and I'm more than happy to let Shuttleworth, Jobs and Ballmer take that grief. Still... What I CAN do is implement a "[LOCAL+3]" syntax, so that if you're in New York and your girl friend is in LA, and you want to display the time where she is (somewhere in TW), you can use that syntax and it will remain correct over the switch. That means you can display correctly any current date and/or time in the world where the difference from either Greenwich or your local time is static. Doesn't help if you're in England and you want to display time in New York, I know, it would have to be just changed manually, I can't get time from a browser/OS running elsewhere... but it seems like the right direction. It will delay things, of course (not that I have any idea how long it WAS going to take), but it seems like it might forestall more requests and make it more generally useful. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to TiddlyWiki@googlegroups.com To unsubscribe from this group, send email to tiddlywiki+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/TiddlyWiki?hl=en -~----------~----~----~----~------~----~------~--~---
