Re: [O] Time-zone in dates
On Tue, 07 Jul 2015, Russell Adams wrote: On Wed, Jul 01, 2015 at 12:22:43PM +0100, Eric S Fraga wrote: I particularly like the single event (a flight) that requires more than one time zone to make sense. My diary is chock full of cases where it looks like a flight out somewhere takes 2 hours but coming back takes 11! (strong winds ;-) I believe this doesn't disprove the need for storing in UTC. [...] After all there's no data lost in the plane example other than the relative timezone of the observer. The relative timezone of the observer is important, though, because that's how you enter the information, and it's often the most logical way to display the information. If you just store UTC there's no way to regenerate that. Though all of that said, just storing UTC is significantly easier, and while I'd love to see a complete implementation, an incomplete implementation which could be expanded to become complete would be a great advance. -- Don Armstrong http://www.donarmstrong.com This can't be happening to me. I've got tenure. -- James Hynes _Publish and Perish_
Re: [O] Time-zone in dates
On Wed, Jul 08, 2015 at 10:59:54AM -0500, Don Armstrong wrote: The relative timezone of the observer is important, though, because that's how you enter the information, and it's often the most logical way to display the information. If you just store UTC there's no way to regenerate that. I'd suggest that the relative timezone of the observer is normally the same, and if it should differ a display override sounds appropriate. Though all of that said, just storing UTC is significantly easier, and while I'd love to see a complete implementation, an incomplete implementation which could be expanded to become complete would be a great advance. I think the question is would supporting timezones be difficult to add? Then would you store the time in UTC only, or support a full timestamp that included timezone? Finally when being displayed they can use the user's $TZ by default, and maybe a suffix of @ TZ inside the date syntax? -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: [O] Time-zone in dates
On Wednesday, 8 Jul 2015 at 11:16, Russell Adams wrote: [...] Then would you store the time in UTC only, or support a full timestamp that included timezone? Finally when being displayed they can use the user's $TZ by default, and maybe a suffix of @ TZ inside the date syntax? The ideal implementation, in my opinion, would have time stamps defined stored with time zone information, as given by the user when creating them (although this could default to UTC, say, if not present in the time stamp) but displayed according to the user's $TZ (or overridden with emacs variable) in cases like agenda views. For upwards compatibility, however, it might be best if time stamps with no time zone information be considered to be at the user's timezone, as it is now. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1260-gcedef7
Re: [O] Time-zone in dates
On 2015-07-08 Wed 09:40, Eric S Fraga wrote: On Wednesday, 8 Jul 2015 at 11:16, Russell Adams wrote: [...] Then would you store the time in UTC only, or support a full timestamp that included timezone? Finally when being displayed they can use the user's $TZ by default, and maybe a suffix of @ TZ inside the date syntax? The ideal implementation, in my opinion, would have time stamps defined stored with time zone information, as given by the user when creating them (although this could default to UTC, say, if not present in the time stamp) but displayed according to the user's $TZ (or overridden with emacs variable) in cases like agenda views. I like this proposal because it solves the problem at hand (as far as I can tell) but isn’t over-engineered. I also like that the date string that the user sees would be the string stored in the file, at least in the default case (non-agenda view). The mostly literal display of files is what sets org-mode apart from other outlines because that allows users to take full advantage of Emacs’ powerful text editing capabilities. For upwards compatibility, however, it might be best if time stamps with no time zone information be considered to be at the user's timezone, as it is now. This point is important. Whatever the solution is it should not break documents and workflows for users who don’t care about time zones. I agree that time zones are important for some people but let’s face it, org-mode made it thus far without support time zones, which suggests that it’s not that big of a deal for most users. Titus signature.asc Description: PGP signature
Re: [O] Time-zone in dates
On Wed, 01 Jul 2015, Michael Brand wrote: On Wed, Jul 1, 2015 at 8:27 AM, Eric S Fraga e.fr...@ucl.ac.uk wrote: On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote: In what way are you losing information? Sorry, should have been clear: the time zone information itself. By reducing to UTC, you lose one bit of information. Whether that matters or not in practice is not clear but I'm always uncomfortable when considering data representations that lead to information loss. I've been trying to come up with an example that would illustrate the problem but I've failed so far. As an example for the above I suggest to consider a non-stop flight with a duration of 1:31:00 from Salt Lake City UT to Phoenix AZ, both cities in different time zones, here intentionally even the same basic time zone but one with daylight saving and one without. [...] 2) When the Org file format would support time zones I would use * Flight from Salt Lake City UT to Phoenix AZ 2015-07-01 Wed 10:55 MDT--2015-07-01 Wed 11:26 MST - *Advantage*: Visibility of the time zones where the event takes place. Of course, this is even more complicated, as MST could mean UTC+08, UTC-07 or UTC+06:30. That said, lets not make perfect the enemy of the good. I've currently got emacs running under TZ=America/Los_Angeles even though my machine is in TZ=America/Chicago precisely because org mode can't yet handle this. I'd be willing to help out as much as I'm able, too. -- Don Armstrong http://www.donarmstrong.com I have no use for before and after pictures. I can't remember starting, and I'm never done. -- a softer world #221 http://www.asofterworld.com/index.php?id=221
Re: [O] Time-zone in dates
On Wed, Jul 01, 2015 at 12:22:43PM +0100, Eric S Fraga wrote: Michael, thanks for some brilliant use cases! I particularly like the single event (a flight) that requires more than one time zone to make sense. My diary is chock full of cases where it looks like a flight out somewhere takes 2 hours but coming back takes 11! (strong winds ;-) -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1260-gcedef7 I believe this doesn't disprove the need for storing in UTC. I just think it means that you need a display filter that can specify a timezone. It sounds like most of your times will be correct using your system time, and if you have something that needs to be displayed in a different timezone, specify it for that one entry. After all there's no data lost in the plane example other than the relative timezone of the observer. The duration is fixed, and the UTC times are exact. Only the observer changes timezone. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: [O] Time-zone in dates
Hi all On Wed, Jul 1, 2015 at 8:27 AM, Eric S Fraga e.fr...@ucl.ac.uk wrote: On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote: In what way are you losing information? Sorry, should have been clear: the time zone information itself. By reducing to UTC, you lose one bit of information. Whether that matters or not in practice is not clear but I'm always uncomfortable when considering data representations that lead to information loss. I've been trying to come up with an example that would illustrate the problem but I've failed so far. As an example for the above I suggest to consider a non-stop flight with a duration of 1:31:00 from Salt Lake City UT to Phoenix AZ, both cities in different time zones, here intentionally even the same basic time zone but one with daylight saving and one without. Funnily enough, the one example I can think of that would be difficult to manage with UTC is the case of not wanting to specify a time zone. Somewhat contrived but, for instance, wanting to do something every morning such as brushing my teeth. This would be, say, at 7am regardless of which time zone I'm in. If this were stored in UTC, it would be at a different time depending on where I was at the time. As an example for the above I suggest to consider noon as an event bound enough to local time. Furthermore, e. g. astronomical events can serve as examples not bound to locality. Or for Eric: A telepresence meeting with the team in South Australia and the team in UK that is in one single global Org agenda file shared between the teams. 1) Current Org that supports only local time without time zone * Flight from Salt Lake City UT to Phoenix AZ 2015-07-01 Wed 10:55--2015-07-01 Wed 11:26 - *Problem*: Valid only in matching local time zone, here MDT and MST. * Next noon 2015-07-01 Wed 12:00 * Next new moon 2015-07-16 Thu 03:24 - *Problem*: Valid only in matching local time zone, here CEST. 2) When the Org file format would support time zones I would use * Flight from Salt Lake City UT to Phoenix AZ 2015-07-01 Wed 10:55 MDT--2015-07-01 Wed 11:26 MST - *Advantage*: Visibility of the time zones where the event takes place. * Next noon 2015-07-01 Wed 12:00 * Next new moon 2015-07-16 Thu 01:24 UTC - *Advantage*: Visibility of neutrality regarding time zones. All three examples are convertible to all local time zones. 3) When the Org file format would not support different time zones but only UTC and Org would support only conversions from and to current local time for display and input then it is not visible that departure and arrival are in different time zones and in which time zones they are * Flight from Salt Lake City UT to Phoenix AZ 2015-07-01 Wed 16:55 UTC--2015-07-01 Wed 18:26 UTC * Next noon 2015-07-01 Wed 10:00 UTC - *Problem*: Valid only in matching local time zone, here CEST. * Next new moon 2015-07-16 Thu 01:24 UTC Time zones used in the examples - MST :: Mountain Standard Time / Mountain Time (Standard Time), UTC-0700 - MDT :: Mountain Daylight Time (Daylight Saving Time), UTC-0600 - CEST :: Central European Summer Time (Daylight Saving Time), UTC+0200 Michael
Re: [O] Time-zone in dates
Michael, thanks for some brilliant use cases! I particularly like the single event (a flight) that requires more than one time zone to make sense. My diary is chock full of cases where it looks like a flight out somewhere takes 2 hours but coming back takes 11! (strong winds ;-) -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1260-gcedef7
Re: [O] Time-zone in dates
Eric S Fraga e.fr...@ucl.ac.uk writes: On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote: Eric S Fraga e.fr...@ucl.ac.uk writes: On Monday, 29 Jun 2015 at 21:17, Nick Dokos wrote: The only reliable way of doing that is to use UTC as the internal representation and translate to/from local time on external display/input *only*. In the case of org mode, the internal representation is user-visible, so that can cause confusion and some head-scratching. But *any* other method is going to be a nightmare (damhikt). This may be the correct approach although I worry about losing information by only storing UTC. Whether this information loss is important or not is difficult to predict. It may be of ephemeral importance only. In what way are you losing information? Sorry, should have been clear: the time zone information itself. By reducing to UTC, you lose one bit of information. Whether that matters or not in practice is not clear but I'm always uncomfortable when considering data representations that lead to information loss. I've been trying to come up with an example that would illustrate the problem but I've failed so far. Funnily enough, the one example I can think of that would be difficult to manage with UTC is the case of not wanting to specify a time zone. Somewhat contrived but, for instance, wanting to do something every morning such as brushing my teeth. This would be, say, at 7am regardless of which time zone I'm in. If this were stored in UTC, it would be at a different time depending on where I was at the time. This is actually a pretty good example. This and Michael Brand's examples make it clear that storing (just) UTC in the file is untenable. Nick
Re: [O] Time-zone in dates
My initial case was very similar to the one Michael described in the telepresence example, except that in my case, I need to assign shifts to people living in different timezones. I.e. I need to make sure that a shift assigned to someone in Illinois will end at the same time when the shift of someone from California begins. One way of doing this is to set all times in UTC+0, but some of us (especially myself :) live very close to UTC+0, so I can accidentally confuse my local time with the universal time. It would be also nicer if shifts were in the local time of people assigned to them too. On Wed, Jul 1, 2015 at 6:17 PM, Nick Dokos ndo...@gmail.com wrote: Eric S Fraga e.fr...@ucl.ac.uk writes: On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote: Eric S Fraga e.fr...@ucl.ac.uk writes: On Monday, 29 Jun 2015 at 21:17, Nick Dokos wrote: The only reliable way of doing that is to use UTC as the internal representation and translate to/from local time on external display/input *only*. In the case of org mode, the internal representation is user-visible, so that can cause confusion and some head-scratching. But *any* other method is going to be a nightmare (damhikt). This may be the correct approach although I worry about losing information by only storing UTC. Whether this information loss is important or not is difficult to predict. It may be of ephemeral importance only. In what way are you losing information? Sorry, should have been clear: the time zone information itself. By reducing to UTC, you lose one bit of information. Whether that matters or not in practice is not clear but I'm always uncomfortable when considering data representations that lead to information loss. I've been trying to come up with an example that would illustrate the problem but I've failed so far. Funnily enough, the one example I can think of that would be difficult to manage with UTC is the case of not wanting to specify a time zone. Somewhat contrived but, for instance, wanting to do something every morning such as brushing my teeth. This would be, say, at 7am regardless of which time zone I'm in. If this were stored in UTC, it would be at a different time depending on where I was at the time. This is actually a pretty good example. This and Michael Brand's examples make it clear that storing (just) UTC in the file is untenable. Nick
Re: [O] Time-zone in dates
On Tuesday, 30 Jun 2015 at 11:08, Nick Dokos wrote: Eric S Fraga e.fr...@ucl.ac.uk writes: On Monday, 29 Jun 2015 at 21:17, Nick Dokos wrote: The only reliable way of doing that is to use UTC as the internal representation and translate to/from local time on external display/input *only*. In the case of org mode, the internal representation is user-visible, so that can cause confusion and some head-scratching. But *any* other method is going to be a nightmare (damhikt). This may be the correct approach although I worry about losing information by only storing UTC. Whether this information loss is important or not is difficult to predict. It may be of ephemeral importance only. In what way are you losing information? Sorry, should have been clear: the time zone information itself. By reducing to UTC, you lose one bit of information. Whether that matters or not in practice is not clear but I'm always uncomfortable when considering data representations that lead to information loss. I've been trying to come up with an example that would illustrate the problem but I've failed so far. Funnily enough, the one example I can think of that would be difficult to manage with UTC is the case of not wanting to specify a time zone. Somewhat contrived but, for instance, wanting to do something every morning such as brushing my teeth. This would be, say, at 7am regardless of which time zone I'm in. If this were stored in UTC, it would be at a different time depending on where I was at the time. Enough rambling for the morning. Time to get some work done! :) -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1260-gcedef7
Re: [O] Time-zone in dates
On Monday, 29 Jun 2015 at 21:17, Nick Dokos wrote: The only reliable way of doing that is to use UTC as the internal representation and translate to/from local time on external display/input *only*. In the case of org mode, the internal representation is user-visible, so that can cause confusion and some head-scratching. But *any* other method is going to be a nightmare (damhikt). This may be the correct approach although I worry about losing information by only storing UTC. Whether this information loss is important or not is difficult to predict. It may be of ephemeral importance only. -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-1261-g304f84
Re: [O] Time-zone in dates
Eric S Fraga e.fr...@ucl.ac.uk writes: On Monday, 29 Jun 2015 at 21:17, Nick Dokos wrote: The only reliable way of doing that is to use UTC as the internal representation and translate to/from local time on external display/input *only*. In the case of org mode, the internal representation is user-visible, so that can cause confusion and some head-scratching. But *any* other method is going to be a nightmare (damhikt). This may be the correct approach although I worry about losing information by only storing UTC. Whether this information loss is important or not is difficult to predict. It may be of ephemeral importance only. In what way are you losing information?
Re: [O] Time-zone in dates
On Friday, 26 Jun 2015 at 21:57, franc...@avalenn.eu wrote: [...] It is really simpler programmatically to deal with time offsets instead. The downside is that you cannot manage DST and other similar peculiarities but the API is much simpler to write. Time offsets are not sufficient. My Australia experience involved me living in South Australia while working with colleagues in the UK. The time difference throughout the year was one of 8.5 hours, 9.5 hours or 10.5 hours, depending on the various switches to and from daylight savings. Very annoying and confusing to manage... To be effective and usable, org will need to incorporate time zone information. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1253-gaa9c4b
Re: [O] Time-zone in dates
Eric S Fraga e.fr...@ucl.ac.uk writes: On Friday, 26 Jun 2015 at 21:57, franc...@avalenn.eu wrote: [...] It is really simpler programmatically to deal with time offsets instead. The downside is that you cannot manage DST and other similar peculiarities but the API is much simpler to write. Time offsets are not sufficient. My Australia experience involved me living in South Australia while working with colleagues in the UK. The time difference throughout the year was one of 8.5 hours, 9.5 hours or 10.5 hours, depending on the various switches to and from daylight savings. Very annoying and confusing to manage... To be effective and usable, org will need to incorporate time zone information. The only reliable way of doing that is to use UTC as the internal representation and translate to/from local time on external display/input *only*. In the case of org mode, the internal representation is user-visible, so that can cause confusion and some head-scratching. But *any* other method is going to be a nightmare (damhikt). -- Nick
[O] Time-zone in dates
Hello, list. I was looking for a way to add time-zone to the date recrod, something like: 2015-07-05 Sun 20:00 GMT+0. I was told that it's very likely that the functionality isn't there, so I wonder if it's really so, and if indeed so, then what would it take to add it? I've asked the same question here: http://emacs.stackexchange.com/questions/13463/specify-timezone-in-org-date-format just in case you saw it earlier. Best. Oleg
Re: [O] Time-zone in dates
Eric S Fraga e.fr...@ucl.ac.uk writes: On Friday, 26 Jun 2015 at 16:40, Oleg Sivokon wrote: Hello, list. I was looking for a way to add time-zone to the date recrod, something like: 2015-07-05 Sun 20:00 GMT+0. I was told that it's very likely that the functionality isn't there, so I wonder if it's really so, and if indeed so, then what would it take to add it? It is indeed so. What would it take? Somebody to program the functionality in but this is a major challenge as time stamps are a fundamental building block of org and it would likely need to be upwards compatible... I can see that being a real pain. The simple way would 'just' be to convert everything to UTC in the background for comparison. Nothing I want to do! Dave
Re: [O] Time-zone in dates
On Friday, 26 Jun 2015 at 16:40, Oleg Sivokon wrote: Hello, list. I was looking for a way to add time-zone to the date recrod, something like: 2015-07-05 Sun 20:00 GMT+0. I was told that it's very likely that the functionality isn't there, so I wonder if it's really so, and if indeed so, then what would it take to add it? It is indeed so. What would it take? Somebody to program the functionality in but this is a major challenge as time stamps are a fundamental building block of org and it would likely need to be upwards compatible... -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1247-ga833d3
Re: [O] Time-zone in dates
On Fri, Jun 26, 2015 at 5:12 PM, Eric S Fraga e.fr...@ucl.ac.uk wrote: Somebody to program the functionality in but this is a major challenge as time stamps are a fundamental building block of org and it would likely need to be upwards compatible... -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1247-ga833d3 Thanks for the info, Eric. I imagined this wouldn't be easy, but I would be interested to know whether there might be some suggestions, possibly to split the work up into stages. For example, perhaps, at first one could only live with dates typed in in that format, but the calendar wouldn't offer an interface to input them. Perhaps there could be even more fine-grained stages. I'm also not entirely sure, but I have a feeling that that might be a problem as well: does interoperability with Calc require certain date format? Would Calc have to also have to support this, once added? Thanks. Oleg
Re: [O] Time-zone in dates
On Friday, 26 Jun 2015 at 10:38, J. David Boyd wrote: [...] I can see that being a real pain. The simple way would 'just' be to convert everything to UTC in the background for comparison. Having spent a year essentially commuting between Australia and the UK a couple of years ago, I can tell you that there is no simple solution... :( The simplest solution for me was firstly to use org (of course :-), then put in all time stamps as local time and finally ensure that the time zone setting for the computer itself, e.g. a laptop, matched where I was at the time. This turns out to be more human oriented than having to worry about time zones, especially when it comes to extra complications like summer time. In practice, I do not miss having time zone information in org. YMMV, of course! -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-1247-ga833d3
Re: [O] Time-zone in dates
Hello, Eric S Fraga e.fr...@ucl.ac.uk writes: In practice, I do not miss having time zone information in org. Time zone information is interesting when users of different areas are exchanging Org documents. I think it would be useful to have: - a keyword to specify time zone per document. This time zone would apply to every time stamp not defining their own time zone. Default value could be `local' so we would be backward compatible. - a way to specify a time zone per time stamp, overriding the previous keyword. I think it would require to define a proper API for timestamps in order to ensure, e.g., comparisons are done right. Regards, -- Nicolas Goaziou
Re: [O] Time-zone in dates
Hello, On Fri, Jun 26, 2015 at 09:20:00PM +0200, Nicolas Goaziou wrote: Time zone information is interesting when users of different areas are exchanging Org documents. I think it would be useful to have: - a keyword to specify time zone per document. This time zone would apply to every time stamp not defining their own time zone. Default value could be `local' so we would be backward compatible. - a way to specify a time zone per time stamp, overriding the previous keyword. I think it would require to define a proper API for timestamps in order to ensure, e.g., comparisons are done right. Timezones are strange beasts to deal with. It is really simpler programmatically to deal with time offsets instead. The downside is that you cannot manage DST and other similar peculiarities but the API is much simpler to write. Just please don't confuse timezones and time offsets especially in documentation as it is not the same thing and it can lead to confusion. I reread from time to time this note from W3C which explains the difference and why it matters : http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e226 Regards, François
Re: [O] Time-zone in dates
Hello, franc...@avalenn.eu writes: Timezones are strange beasts to deal with. True. It is really simpler programmatically to deal with time offsets instead. The downside is that you cannot manage DST and other similar peculiarities but the API is much simpler to write. However, time offsets are not very interesting. Org is (also) about appointments, deadlines... so timezones are more accurate. Also, Emacs contains timezone.el, which, I assume, should take care of all the heavy duty concerning these beasts, as far as an API is concerned. This requires care, but it should be doable, really, don't you think? Just please don't confuse timezones and time offsets especially in documentation as it is not the same thing and it can lead to confusion. I reread from time to time this note from W3C which explains the difference and why it matters : http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e226 Thank you for the reference. I didn't know about it. Regards, -- Nicolas Goaziou
