Timespan translateToUTC problematic
Ciao, i have a Pharo 4.0 image run on macbook with time zone is set to Rome +1 UTC . When i send the translateToUTC to Date instance it is ok: Date today > 2017-11-16T00:00:00+01:00 Date today translateToUTC > 2017-11-16T00:00:00+00:00 But for Month instance : Month month: 6 year: 2015 > 2015-06-01T00:00:00+01:00 ( Month month: 6 year: 2015 ) translateToUTC > 2015-06-01T00:00:00+01:00 The same problematic is for Year instance. Considerations ? Thanks, Dario
I openend an issue: https://pharo.fogbugz.com/f/cases/20700/translateToUTC-does-not-work-on-Mont... Thank you for reporting -- Pavel 2017-11-16 18:36 GMT+01:00 Trussardi Dario Romano < dario.trussardi@tiscali.it>:
Ciao,
i have a Pharo 4.0 image run on macbook with time zone is set to Rome +1 UTC .
When i send the translateToUTC to Date instance it is ok:
Date today > 2017-11-16T00:00:00+01:00
Date today translateToUTC > 2017-11-16T00:00:00+00:00
But for Month instance :
Month month: 6 year: 2015 > 2015-06-01T00:00:00+01:00
( Month month: 6 year: 2015 ) translateToUTC > 2015-06-01T00:00:00+01:00
The same problematic is for Year instance.
Considerations ?
Thanks,
Dario
I find the concept of translating TZ of a Date silly. The real bug imho should be that it prints both time and TZ.... this is Date, not DateAndTime. Peter On Thu, Nov 16, 2017 at 8:23 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
I openend an issue: https://pharo.fogbugz.com/f/cases/20700/ translateToUTC-does-not-work-on-Month-and-Year
Thank you for reporting -- Pavel
2017-11-16 18:36 GMT+01:00 Trussardi Dario Romano < dario.trussardi@tiscali.it>:
Ciao,
i have a Pharo 4.0 image run on macbook with time zone is set to Rome +1 UTC .
When i send the translateToUTC to Date instance it is ok:
Date today > 2017-11-16T00:00:00+01:00
Date today translateToUTC > 2017-11-16T00:00:00+00:00
But for Month instance :
Month month: 6 year: 2015 > 2015-06-01T00:00:00+01:00
( Month month: 6 year: 2015 ) translateToUTC > 2015-06-01T00:00:00+01:00
The same problematic is for Year instance.
Considerations ?
Thanks,
Dario
On 17 Nov 2017, at 08:49 , Peter Uhnák <i.uhnak@gmail.com> wrote:
I find the concept of translating TZ of a Date silly. The real bug imho should be that it prints both time and TZ.... this is Date, not DateAndTime.
I live in Oregon, and frequently work with people in New Zealand, which is (depending on the time of year) 19 to 21 hours ahead of Oregon. So, when it is 3pm at home, it is noon the next day in New Zealand. This means that in order to know the day of the week, the month, and even the year, of a given instant in UTC, one has to know the timezone that is being referred to. The answer could be Sunday, 31 December 2017 for one observer, and Monday, 1 January 2018 for another. So, contrary to your statement, I donât see how I can know the date without also knowing the Time Zone. Andrew
Because Date has, by definition, no concept of time. The only reason why you see it is because someone decided to save a bit of time and reuse implementation. If you want to move TZ, you need something that _has_ time. Such as DateAndTime. You can also read the comments ... Date
Instances of Date are Timespans with duration of 1 day.
it represents an entire day, not a particular time point DateAndTime
I represent a point in time or timestamp as defined by ISO 8601. I am TimeZone aware.
I really don't understand why are you trying to force TZ into Date against it's purpose when you have a class that does exactly what you want and was built for that purpose. Peter On Fri, Nov 17, 2017 at 12:09 PM, Prof. Andrew P. Black <black@cs.pdx.edu> wrote:
On 17 Nov 2017, at 08:49 , Peter Uhnák <i.uhnak@gmail.com> wrote:
I find the concept of translating TZ of a Date silly. The real bug imho should be that it prints both time and TZ.... this is Date, not DateAndTime.
I live in Oregon, and frequently work with people in New Zealand, which is (depending on the time of year) 19 to 21 hours ahead of Oregon. So, when it is 3pm at home, it is noon *the next day* in New Zealand.
This means that in order to know the day of the week, the month, and even the year, of a given instant in UTC, one has to know the timezone that is being referred to. The answer could be Sunday, 31 December 2017 for one observer, and Monday, 1 January 2018 for another.
So, contrary to your statement, I donât see how I can know the date without also knowing the Time Zone.
Andrew
Both interpretation are correct and valid, it is just hard to capture them with one class. In normal human conversation and in the abstract, of course a date is just a year/month/date triple. But that is because most people only look at this from their own perspective. However, from an international perspective, of course it must include time zone info. Remember end-of-year/new-year, with all those articles about people in other countries partying or having fireworks earlier/later. Date transitions are different in each time zone, so to talk accurately about a date, you need the context of a time zone. Whether that timezone is actually part of the date object is another discussion, but there is always the timezone context even if it is implicit ('of course I mean my own timezone and not yours').
On 17 Nov 2017, at 14:19, Peter Uhnák <i.uhnak@gmail.com> wrote:
Because Date has, by definition, no concept of time. The only reason why you see it is because someone decided to save a bit of time and reuse implementation.
If you want to move TZ, you need something that _has_ time. Such as DateAndTime.
You can also read the comments ...
Date
Instances of Date are Timespans with duration of 1 day.
it represents an entire day, not a particular time point
DateAndTime
I represent a point in time or timestamp as defined by ISO 8601. I am TimeZone aware.
I really don't understand why are you trying to force TZ into Date against it's purpose when you have a class that does exactly what you want and was built for that purpose.
Peter
On Fri, Nov 17, 2017 at 12:09 PM, Prof. Andrew P. Black <black@cs.pdx.edu> wrote:
On 17 Nov 2017, at 08:49 , Peter Uhnák <i.uhnak@gmail.com> wrote:
I find the concept of translating TZ of a Date silly. The real bug imho should be that it prints both time and TZ.... this is Date, not DateAndTime.
I live in Oregon, and frequently work with people in New Zealand, which is (depending on the time of year) 19 to 21 hours ahead of Oregon. So, when it is 3pm at home, it is noon the next day in New Zealand.
This means that in order to know the day of the week, the month, and even the year, of a given instant in UTC, one has to know the timezone that is being referred to. The answer could be Sunday, 31 December 2017 for one observer, and Monday, 1 January 2018 for another.
So, contrary to your statement, I donât see how I can know the date without also knowing the Time Zone.
Andrew
On 17 November 2017 at 14:44, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Both interpretation are correct and valid, it is just hard to capture them with one class.
In normal human conversation and in the abstract, of course a date is just a year/month/date triple. But that is because most people only look at this from their own perspective. However, from an international perspective, of course it must include time zone info. Remember end-of-year/new-year, with all those articles about people in other countries partying or having fireworks earlier/later.
Date transitions are different in each time zone, so to talk accurately about a date, you need the context of a time zone.
I don't think this is correct. If we take CEST (UTC+1) and AEDT (UTC+11) as an example: From midnight to 14:00 UTC the dates are the same. From 14:00 - 24:00 CEST Australia is one day ahead. How can this be interpreted sensibly given only a date? Unless I'm missing something, I think Peter is correct and that a Date shouldn't have any concept of timezone. Cheers, Alistair
Whether that timezone is actually part of the date object is another discussion, but there is always the timezone context even if it is implicit ('of course I mean my own timezone and not yours').
On 17 Nov 2017, at 14:19, Peter Uhnák <i.uhnak@gmail.com> wrote:
Because Date has, by definition, no concept of time. The only reason why you see it is because someone decided to save a bit of time and reuse implementation.
If you want to move TZ, you need something that _has_ time. Such as DateAndTime.
You can also read the comments ...
Date
Instances of Date are Timespans with duration of 1 day.
it represents an entire day, not a particular time point
DateAndTime
I represent a point in time or timestamp as defined by ISO 8601. I am TimeZone aware.
I really don't understand why are you trying to force TZ into Date against it's purpose when you have a class that does exactly what you want and was built for that purpose.
Peter
On Fri, Nov 17, 2017 at 12:09 PM, Prof. Andrew P. Black <black@cs.pdx.edu> wrote:
On 17 Nov 2017, at 08:49 , Peter Uhnák <i.uhnak@gmail.com> wrote:
I find the concept of translating TZ of a Date silly. The real bug imho should be that it prints both time and TZ.... this is Date, not DateAndTime.
I live in Oregon, and frequently work with people in New Zealand, which is (depending on the time of year) 19 to 21 hours ahead of Oregon. So, when it is 3pm at home, it is noon the next day in New Zealand.
This means that in order to know the day of the week, the month, and even the year, of a given instant in UTC, one has to know the timezone that is being referred to. The answer could be Sunday, 31 December 2017 for one observer, and Monday, 1 January 2018 for another.
So, contrary to your statement, I donât see how I can know the date without also knowing the Time Zone.
Andrew
On 18 Nov 2017, at 17:46, Alistair Grant <akgrant0710@gmail.com> wrote:
On 17 November 2017 at 14:44, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Both interpretation are correct and valid, it is just hard to capture them with one class.
In normal human conversation and in the abstract, of course a date is just a year/month/date triple. But that is because most people only look at this from their own perspective. However, from an international perspective, of course it must include time zone info. Remember end-of-year/new-year, with all those articles about people in other countries partying or having fireworks earlier/later.
Date transitions are different in each time zone, so to talk accurately about a date, you need the context of a time zone.
I don't think this is correct.
If we take CEST (UTC+1) and AEDT (UTC+11) as an example: From midnight to 14:00 UTC the dates are the same. From 14:00 - 24:00 CEST Australia is one day ahead.
How can this be interpreted sensibly given only a date? Unless I'm missing something, I think Peter is correct and that a Date shouldn't have any concept of timezone.
Inspect and compare the following two Dates: { (DateAndTime fromString: '2018/01/01T00:00:00+11') asDate. (DateAndTime fromString: '2018/01/01T00:00:00+01') asDate }. This is as if you typed 'Date today' at the beginning of next January 1st in your timezone or mine. Both print as '1 January 2018'. In some sense they are equal (the abstract, context free view), but as a timespan [start,stop] interval they are different, they do not include the same points in time. By having the timezone in there, the ambiguity is resolved. That is because the exact start moment is different: { (DateAndTime fromString: '2018/01/01T00:00:00+11') asUTC. (DateAndTime fromString: '2018/01/01T00:00:00+01') asUTC }. BTW, my ZTimestamp package is an alternative DateAndTime object that is (1) always in UTC, and thus contains no timezone and (2) has second precision. It is half the size and faster to work with. By using its accompanying ZTimezone class that loads the Olsen DB, you do the necessary conversions when presenting to humans. That of course then requires the context (current or applicable timezone) to be supplied externally. (ZTimezone id: 'Australia/Sydney') gmtToLocal: ZTimestamp now. HTH, Sven
Cheers, Alistair
Whether that timezone is actually part of the date object is another discussion, but there is always the timezone context even if it is implicit ('of course I mean my own timezone and not yours').
On 17 Nov 2017, at 14:19, Peter Uhnák <i.uhnak@gmail.com> wrote:
Because Date has, by definition, no concept of time. The only reason why you see it is because someone decided to save a bit of time and reuse implementation.
If you want to move TZ, you need something that _has_ time. Such as DateAndTime.
You can also read the comments ...
Date
Instances of Date are Timespans with duration of 1 day.
it represents an entire day, not a particular time point
DateAndTime
I represent a point in time or timestamp as defined by ISO 8601. I am TimeZone aware.
I really don't understand why are you trying to force TZ into Date against it's purpose when you have a class that does exactly what you want and was built for that purpose.
Peter
On Fri, Nov 17, 2017 at 12:09 PM, Prof. Andrew P. Black <black@cs.pdx.edu> wrote:
On 17 Nov 2017, at 08:49 , Peter Uhnák <i.uhnak@gmail.com> wrote:
I find the concept of translating TZ of a Date silly. The real bug imho should be that it prints both time and TZ.... this is Date, not DateAndTime.
I live in Oregon, and frequently work with people in New Zealand, which is (depending on the time of year) 19 to 21 hours ahead of Oregon. So, when it is 3pm at home, it is noon the next day in New Zealand.
This means that in order to know the day of the week, the month, and even the year, of a given instant in UTC, one has to know the timezone that is being referred to. The answer could be Sunday, 31 December 2017 for one observer, and Monday, 1 January 2018 for another.
So, contrary to your statement, I donât see how I can know the date without also knowing the Time Zone.
Andrew
On 18 November 2017 at 18:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 18 Nov 2017, at 17:46, Alistair Grant <akgrant0710@gmail.com> wrote:
On 17 November 2017 at 14:44, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Both interpretation are correct and valid, it is just hard to capture them with one class.
In normal human conversation and in the abstract, of course a date is just a year/month/date triple. But that is because most people only look at this from their own perspective. However, from an international perspective, of course it must include time zone info. Remember end-of-year/new-year, with all those articles about people in other countries partying or having fireworks earlier/later.
Date transitions are different in each time zone, so to talk accurately about a date, you need the context of a time zone.
I don't think this is correct.
If we take CEST (UTC+1) and AEDT (UTC+11) as an example: From midnight to 14:00 UTC the dates are the same. From 14:00 - 24:00 CEST Australia is one day ahead.
How can this be interpreted sensibly given only a date? Unless I'm missing something, I think Peter is correct and that a Date shouldn't have any concept of timezone.
Inspect and compare the following two Dates:
{ (DateAndTime fromString: '2018/01/01T00:00:00+11') asDate. (DateAndTime fromString: '2018/01/01T00:00:00+01') asDate }.
This is as if you typed 'Date today' at the beginning of next January 1st in your timezone or mine. Both print as '1 January 2018'. In some sense they are equal (the abstract, context free view), but as a timespan [start,stop] interval they are different, they do not include the same points in time. By having the timezone in there, the ambiguity is resolved. That is because the exact start moment is different:
{ (DateAndTime fromString: '2018/01/01T00:00:00+11') asUTC. (DateAndTime fromString: '2018/01/01T00:00:00+01') asUTC }.
Sven, thanks for your reply. I haven't thought about this as much as Richard, but came to the same conclusion. I think your comment about being equal "in the abstract, context free view" gets to the core of the issue. A date can be abstract, i.e. just a day, month and year, or it can be a timespan (a 24 hour period starting at a particular timezone). We may know the appropriate timezone when we specify the date, or we may not know until we want to use the date. As an example, take wishing someone happy birthday. I want to know that person's birthday in the abstract. Each year I will want to apply it with timezones, i.e. I'll figure out an appropriate time to contact them given my timezone and their's. Figuring out when to contact them certainly doesn't depend on the timezone I was in when I recorded their birthday, or the timezone they were in when they were born. If I want to know if that person and I have the same birthday, I won't be taking timezones into account. Google Calendar has (had?) exactly this problem. I entered an all day event as a reminder for someone's birthday. When the day came I happened to be in a different timezone and their birthday was from 4pm one day to 4pm the next. I don't remember which timezone I was in when I added the event, and I'm certainly not interested in figuring it out. Which of the two dates covered by this "one date" is the correct one? It should be easy to convert an abstract date to a concrete date, i.e. one with a specified timezone, but I think they are two different concepts. Thanks! Alistair
BTW, my ZTimestamp package is an alternative DateAndTime object that is (1) always in UTC, and thus contains no timezone and (2) has second precision. It is half the size and faster to work with.
By using its accompanying ZTimezone class that loads the Olsen DB, you do the necessary conversions when presenting to humans. That of course then requires the context (current or applicable timezone) to be supplied externally.
(ZTimezone id: 'Australia/Sydney') gmtToLocal: ZTimestamp now.
HTH,
Sven
Cheers, Alistair
Whether that timezone is actually part of the date object is another discussion, but there is always the timezone context even if it is implicit ('of course I mean my own timezone and not yours').
On 17 Nov 2017, at 14:19, Peter Uhnák <i.uhnak@gmail.com> wrote:
Because Date has, by definition, no concept of time. The only reason why you see it is because someone decided to save a bit of time and reuse implementation.
If you want to move TZ, you need something that _has_ time. Such as DateAndTime.
You can also read the comments ...
Date
Instances of Date are Timespans with duration of 1 day.
it represents an entire day, not a particular time point
DateAndTime
I represent a point in time or timestamp as defined by ISO 8601. I am TimeZone aware.
I really don't understand why are you trying to force TZ into Date against it's purpose when you have a class that does exactly what you want and was built for that purpose.
Peter
On Fri, Nov 17, 2017 at 12:09 PM, Prof. Andrew P. Black <black@cs.pdx.edu> wrote:
On 17 Nov 2017, at 08:49 , Peter Uhnák <i.uhnak@gmail.com> wrote:
I find the concept of translating TZ of a Date silly. The real bug imho should be that it prints both time and TZ.... this is Date, not DateAndTime.
I live in Oregon, and frequently work with people in New Zealand, which is (depending on the time of year) 19 to 21 hours ahead of Oregon. So, when it is 3pm at home, it is noon the next day in New Zealand.
This means that in order to know the day of the week, the month, and even the year, of a given instant in UTC, one has to know the timezone that is being referred to. The answer could be Sunday, 31 December 2017 for one observer, and Monday, 1 January 2018 for another.
So, contrary to your statement, I donât see how I can know the date without also knowing the Time Zone.
Andrew
On 20 November 2017 at 14:58, Alistair Grant <akgrant0710@gmail.com> wrote:
On 18 November 2017 at 18:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 18 Nov 2017, at 17:46, Alistair Grant <akgrant0710@gmail.com> wrote:
On 17 November 2017 at 14:44, Sven Van Caekenberghe <sven@stfx.eu>
wrote:
Both interpretation are correct and valid, it is just hard to capture them with one class.
In normal human conversation and in the abstract, of course a date is just a year/month/date triple. But that is because most people only look at this from their own perspective. However, from an international perspective, of course it must include time zone info. Remember end-of-year/new-year, with all those articles about people in other countries partying or having fireworks earlier/later.
Date transitions are different in each time zone, so to talk accurately about a date, you need the context of a time zone.
I don't think this is correct.
If we take CEST (UTC+1) and AEDT (UTC+11) as an example: From midnight to 14:00 UTC the dates are the same. From 14:00 - 24:00 CEST Australia is one day ahead.
How can this be interpreted sensibly given only a date? Unless I'm missing something, I think Peter is correct and that a Date shouldn't have any concept of timezone.
Inspect and compare the following two Dates:
{ (DateAndTime fromString: '2018/01/01T00:00:00+11') asDate. (DateAndTime fromString: '2018/01/01T00:00:00+01') asDate }.
This is as if you typed 'Date today' at the beginning of next January 1st in your timezone or mine. Both print as '1 January 2018'. In some sense they are equal (the abstract, context free view), but as a timespan [start,stop] interval they are different, they do not include the same points in time. By having the timezone in there, the ambiguity is resolved. That is because the exact start moment is different:
{ (DateAndTime fromString: '2018/01/01T00:00:00+11') asUTC. (DateAndTime fromString: '2018/01/01T00:00:00+01') asUTC }.
Sven, thanks for your reply. I haven't thought about this as much as Richard, but came to the same conclusion.
I think your comment about being equal "in the abstract, context free view" gets to the core of the issue.
A date can be abstract, i.e. just a day, month and year, or it can be a timespan (a 24 hour period starting at a particular timezone). We may know the appropriate timezone when we specify the date, or we may not know until we want to use the date.
As an example, take wishing someone happy birthday. I want to know that person's birthday in the abstract. Each year I will want to apply it with timezones, i.e. I'll figure out an appropriate time to contact them given my timezone and their's. Figuring out when to contact them certainly doesn't depend on the timezone I was in when I recorded their birthday, or the timezone they were in when they were born. If I want to know if that person and I have the same birthday, I won't be taking timezones into account.
Nice examples. They made a lot of sense.
Google Calendar has (had?) exactly this problem. I entered an all day event as a reminder for someone's birthday. When the day came I happened to be in a different timezone and their birthday was from 4pm one day to 4pm the next. I don't remember which timezone I was in when I added the event, and I'm certainly not interested in figuring it out. Which of the two dates covered by this "one date" is
the correct one?
Obviously GodGoog should know this date was associated with a particular person, and since they're happy with GG geo-tracking their location, GG should have adapted. Sounds like a bug to me. \ ;^)-cheers-ben /
It should be easy to convert an abstract date to a concrete date, i.e. one with a specified timezone, but I think they are two different concepts.
Thanks! Alistair
BTW, my ZTimestamp package is an alternative DateAndTime object that is (1) always in UTC, and thus contains no timezone and (2) has second precision. It is half the size and faster to work with.
By using its accompanying ZTimezone class that loads the Olsen DB, you do the necessary conversions when presenting to humans. That of course then requires the context (current or applicable timezone) to be supplied externally.
(ZTimezone id: 'Australia/Sydney') gmtToLocal: ZTimestamp now.
HTH,
Sven
Cheers, Alistair
Whether that timezone is actually part of the date object is another discussion, but there is always the timezone context even if it is implicit ('of course I mean my own timezone and not yours').
On 17 Nov 2017, at 14:19, Peter Uhnák <i.uhnak@gmail.com> wrote:
Because Date has, by definition, no concept of time. The only reason why you see it is because someone decided to save a bit of time and reuse implementation.
If you want to move TZ, you need something that _has_ time. Such as DateAndTime.
You can also read the comments ...
Date
Instances of Date are Timespans with duration of 1 day.
it represents an entire day, not a particular time point
DateAndTime
I represent a point in time or timestamp as defined by ISO 8601. I am TimeZone aware.
I really don't understand why are you trying to force TZ into Date against it's purpose when you have a class that does exactly what you want and was built for that purpose.
Peter
On Fri, Nov 17, 2017 at 12:09 PM, Prof. Andrew P. Black < black@cs.pdx.edu> wrote:
On 17 Nov 2017, at 08:49 , Peter Uhnák <i.uhnak@gmail.com> wrote:
I find the concept of translating TZ of a Date silly. The real bug imho should be that it prints both time and TZ.... this is Date, not DateAndTime.
I live in Oregon, and frequently work with people in New Zealand, which is (depending on the time of year) 19 to 21 hours ahead of Oregon. So, when it is 3pm at home, it is noon the next day in New Zealand.
This means that in order to know the day of the week, the month, and even the year, of a given instant in UTC, one has to know the timezone that is being referred to. The answer could be Sunday, 31 December 2017 for one observer, and Monday, 1 January 2018 for another.
So, contrary to your statement, I donât see how I can know the date without also knowing the Time Zone.
Andrew
On 20 Nov 2017, at 07:58, Alistair Grant <akgrant0710@gmail.com> wrote:
On 18 November 2017 at 18:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 18 Nov 2017, at 17:46, Alistair Grant <akgrant0710@gmail.com> wrote:
On 17 November 2017 at 14:44, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Both interpretation are correct and valid, it is just hard to capture them with one class.
In normal human conversation and in the abstract, of course a date is just a year/month/date triple. But that is because most people only look at this from their own perspective. However, from an international perspective, of course it must include time zone info. Remember end-of-year/new-year, with all those articles about people in other countries partying or having fireworks earlier/later.
Date transitions are different in each time zone, so to talk accurately about a date, you need the context of a time zone.
I don't think this is correct.
If we take CEST (UTC+1) and AEDT (UTC+11) as an example: From midnight to 14:00 UTC the dates are the same. From 14:00 - 24:00 CEST Australia is one day ahead.
How can this be interpreted sensibly given only a date? Unless I'm missing something, I think Peter is correct and that a Date shouldn't have any concept of timezone.
Inspect and compare the following two Dates:
{ (DateAndTime fromString: '2018/01/01T00:00:00+11') asDate. (DateAndTime fromString: '2018/01/01T00:00:00+01') asDate }.
This is as if you typed 'Date today' at the beginning of next January 1st in your timezone or mine. Both print as '1 January 2018'. In some sense they are equal (the abstract, context free view), but as a timespan [start,stop] interval they are different, they do not include the same points in time. By having the timezone in there, the ambiguity is resolved. That is because the exact start moment is different:
{ (DateAndTime fromString: '2018/01/01T00:00:00+11') asUTC. (DateAndTime fromString: '2018/01/01T00:00:00+01') asUTC }.
Sven, thanks for your reply. I haven't thought about this as much as Richard, but came to the same conclusion.
I think your comment about being equal "in the abstract, context free view" gets to the core of the issue.
A date can be abstract, i.e. just a day, month and year, or it can be a timespan (a 24 hour period starting at a particular timezone). We may know the appropriate timezone when we specify the date, or we may not know until we want to use the date.
As an example, take wishing someone happy birthday. I want to know that person's birthday in the abstract. Each year I will want to apply it with timezones, i.e. I'll figure out an appropriate time to contact them given my timezone and their's. Figuring out when to contact them certainly doesn't depend on the timezone I was in when I recorded their birthday, or the timezone they were in when they were born. If I want to know if that person and I have the same birthday, I won't be taking timezones into account.
Well, that example is exactly why you do need the TZ (in the date or not is another matter). If I, from my TZ, want to be the first to wish you a happy birthday, I have to know your exact TZ. We can discuss about this ad infinitum. I think we all agree that there are 2 views (abstract calendar date and concrete time interval/span, which requires a TZ), as well as 2 possible ways to deal with the second case (TZ inside date or as context outside of the date). Right now, it is TZ inside, but you are free to ignore it. That is how it is, I did not write it, I would probably do it differently myself, but I don't think there is a bug, nor that we have to change it any time soon. There are several alternative packages out there, and everyone can write their own, maybe one will eventually become the most popular as to be the default in the image, but I doubt it.
Google Calendar has (had?) exactly this problem. I entered an all day event as a reminder for someone's birthday. When the day came I happened to be in a different timezone and their birthday was from 4pm one day to 4pm the next. I don't remember which timezone I was in when I added the event, and I'm certainly not interested in figuring it out. Which of the two dates covered by this "one date" is the correct one?
It should be easy to convert an abstract date to a concrete date, i.e. one with a specified timezone, but I think they are two different concepts.
Thanks! Alistair
BTW, my ZTimestamp package is an alternative DateAndTime object that is (1) always in UTC, and thus contains no timezone and (2) has second precision. It is half the size and faster to work with.
By using its accompanying ZTimezone class that loads the Olsen DB, you do the necessary conversions when presenting to humans. That of course then requires the context (current or applicable timezone) to be supplied externally.
(ZTimezone id: 'Australia/Sydney') gmtToLocal: ZTimestamp now.
HTH,
Sven
Cheers, Alistair
Whether that timezone is actually part of the date object is another discussion, but there is always the timezone context even if it is implicit ('of course I mean my own timezone and not yours').
On 17 Nov 2017, at 14:19, Peter Uhnák <i.uhnak@gmail.com> wrote:
Because Date has, by definition, no concept of time. The only reason why you see it is because someone decided to save a bit of time and reuse implementation.
If you want to move TZ, you need something that _has_ time. Such as DateAndTime.
You can also read the comments ...
Date
Instances of Date are Timespans with duration of 1 day.
it represents an entire day, not a particular time point
DateAndTime
I represent a point in time or timestamp as defined by ISO 8601. I am TimeZone aware.
I really don't understand why are you trying to force TZ into Date against it's purpose when you have a class that does exactly what you want and was built for that purpose.
Peter
On Fri, Nov 17, 2017 at 12:09 PM, Prof. Andrew P. Black <black@cs.pdx.edu> wrote:
On 17 Nov 2017, at 08:49 , Peter Uhnák <i.uhnak@gmail.com> wrote:
I find the concept of translating TZ of a Date silly. The real bug imho should be that it prints both time and TZ.... this is Date, not DateAndTime.
I live in Oregon, and frequently work with people in New Zealand, which is (depending on the time of year) 19 to 21 hours ahead of Oregon. So, when it is 3pm at home, it is noon the next day in New Zealand.
This means that in order to know the day of the week, the month, and even the year, of a given instant in UTC, one has to know the timezone that is being referred to. The answer could be Sunday, 31 December 2017 for one observer, and Monday, 1 January 2018 for another.
So, contrary to your statement, I donât see how I can know the date without also knowing the Time Zone.
Andrew
In any case, we have an issue because the behavior of the Date and Month is different -- Pavel 2017-11-20 9:16 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 20 Nov 2017, at 07:58, Alistair Grant <akgrant0710@gmail.com> wrote:
On 18 November 2017 at 18:38, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 18 Nov 2017, at 17:46, Alistair Grant <akgrant0710@gmail.com>
wrote:
On 17 November 2017 at 14:44, Sven Van Caekenberghe <sven@stfx.eu>
wrote:
Both interpretation are correct and valid, it is just hard to capture them with one class.
In normal human conversation and in the abstract, of course a date is just a year/month/date triple. But that is because most people only look at this from their own perspective. However, from an international perspective, of course it must include time zone info. Remember end-of-year/new-year, with all those articles about people in other countries partying or having fireworks earlier/later.
Date transitions are different in each time zone, so to talk accurately about a date, you need the context of a time zone.
I don't think this is correct.
If we take CEST (UTC+1) and AEDT (UTC+11) as an example: From midnight to 14:00 UTC the dates are the same. From 14:00 - 24:00 CEST Australia is one day ahead.
How can this be interpreted sensibly given only a date? Unless I'm missing something, I think Peter is correct and that a Date shouldn't have any concept of timezone.
Inspect and compare the following two Dates:
{ (DateAndTime fromString: '2018/01/01T00:00:00+11') asDate. (DateAndTime fromString: '2018/01/01T00:00:00+01') asDate }.
This is as if you typed 'Date today' at the beginning of next January 1st in your timezone or mine. Both print as '1 January 2018'. In some sense they are equal (the abstract, context free view), but as a timespan [start,stop] interval they are different, they do not include the same points in time. By having the timezone in there, the ambiguity is resolved. That is because the exact start moment is different:
{ (DateAndTime fromString: '2018/01/01T00:00:00+11') asUTC. (DateAndTime fromString: '2018/01/01T00:00:00+01') asUTC }.
Sven, thanks for your reply. I haven't thought about this as much as Richard, but came to the same conclusion.
I think your comment about being equal "in the abstract, context free view" gets to the core of the issue.
A date can be abstract, i.e. just a day, month and year, or it can be a timespan (a 24 hour period starting at a particular timezone). We may know the appropriate timezone when we specify the date, or we may not know until we want to use the date.
As an example, take wishing someone happy birthday. I want to know that person's birthday in the abstract. Each year I will want to apply it with timezones, i.e. I'll figure out an appropriate time to contact them given my timezone and their's. Figuring out when to contact them certainly doesn't depend on the timezone I was in when I recorded their birthday, or the timezone they were in when they were born. If I want to know if that person and I have the same birthday, I won't be taking timezones into account.
Well, that example is exactly why you do need the TZ (in the date or not is another matter). If I, from my TZ, want to be the first to wish you a happy birthday, I have to know your exact TZ.
We can discuss about this ad infinitum. I think we all agree that there are 2 views (abstract calendar date and concrete time interval/span, which requires a TZ), as well as 2 possible ways to deal with the second case (TZ inside date or as context outside of the date).
Right now, it is TZ inside, but you are free to ignore it. That is how it is, I did not write it, I would probably do it differently myself, but I don't think there is a bug, nor that we have to change it any time soon.
There are several alternative packages out there, and everyone can write their own, maybe one will eventually become the most popular as to be the default in the image, but I doubt it.
Google Calendar has (had?) exactly this problem. I entered an all day event as a reminder for someone's birthday. When the day came I happened to be in a different timezone and their birthday was from 4pm one day to 4pm the next. I don't remember which timezone I was in when I added the event, and I'm certainly not interested in figuring it out. Which of the two dates covered by this "one date" is the correct one?
It should be easy to convert an abstract date to a concrete date, i.e. one with a specified timezone, but I think they are two different concepts.
Thanks! Alistair
BTW, my ZTimestamp package is an alternative DateAndTime object that is (1) always in UTC, and thus contains no timezone and (2) has second precision. It is half the size and faster to work with.
By using its accompanying ZTimezone class that loads the Olsen DB, you do the necessary conversions when presenting to humans. That of course then requires the context (current or applicable timezone) to be supplied externally.
(ZTimezone id: 'Australia/Sydney') gmtToLocal: ZTimestamp now.
HTH,
Sven
Cheers, Alistair
Whether that timezone is actually part of the date object is another discussion, but there is always the timezone context even if it is implicit ('of course I mean my own timezone and not yours').
On 17 Nov 2017, at 14:19, Peter Uhnák <i.uhnak@gmail.com> wrote:
Because Date has, by definition, no concept of time. The only reason why you see it is because someone decided to save a bit of time and reuse implementation.
If you want to move TZ, you need something that _has_ time. Such as DateAndTime.
You can also read the comments ...
Date
Instances of Date are Timespans with duration of 1 day.
it represents an entire day, not a particular time point
DateAndTime
I represent a point in time or timestamp as defined by ISO 8601. I am TimeZone aware.
I really don't understand why are you trying to force TZ into Date against it's purpose when you have a class that does exactly what you want and was built for that purpose.
Peter
On Fri, Nov 17, 2017 at 12:09 PM, Prof. Andrew P. Black < black@cs.pdx.edu> wrote:
On 17 Nov 2017, at 08:49 , Peter Uhnák <i.uhnak@gmail.com> wrote:
I find the concept of translating TZ of a Date silly. The real bug imho should be that it prints both time and TZ.... this is Date, not DateAndTime.
I live in Oregon, and frequently work with people in New Zealand, which is (depending on the time of year) 19 to 21 hours ahead of Oregon. So, when it is 3pm at home, it is noon the next day in New Zealand.
This means that in order to know the day of the week, the month, and even the year, of a given instant in UTC, one has to know the timezone that is being referred to. The answer could be Sunday, 31 December 2017 for one observer, and Monday, 1 January 2018 for another.
So, contrary to your statement, I donât see how I can know the date without also knowing the Time Zone.
Andrew
On 20 November 2017 at 09:16, Sven Van Caekenberghe <sven@stfx.eu> wrote:
We can discuss about this ad infinitum. I think we all agree that there are 2 views (abstract calendar date and concrete time interval/span, which requires a TZ), as well as 2 possible ways to deal with the second case (TZ inside date or as context outside of the date).
Right, I think changing things now will be quite a bit of work. However there are a couple of things we can do to make life a bit easier: 1. Add a method that facilitates TZ independent comparisons. 2. Add a bit more information in the class comments. I've named the method #dmyEquals: below, although I don't particularly like it. If anyone has a better idea, please reply. I've also added some proposed text for the class comments. If I don't hear back in a couple of days I'll submit a PR (with automated tests). Cheers, Alistair ---- dmyEquals: aDate "Perform a time zone independent comparison of the dates, i.e. only compare day, month and year" ^self year = aDate year and: [ self monthIndex = aDate monthIndex and: [ self dayOfMonth = aDate dayOfMonth ] ] ---- Class comment: Instances of Date are Timespans with duration of 1 day. Their default creation assumes a start of midnight in the local time zone. !Comparing Dates We tend to use dates in one of two modes: - Time zone dependent - Time zone independent In the first instance, dates are only the same if they are in the same time zone (otherwise they are two different 24 hour periods). This is the default behaviour of Date. In the second, comparison is only interested in whether the day, month and year are the same. As an example, take someone's birthday. If I want to know whether we were born on the same day, I will want to compare dates without time zones. If I want to know if it is currently their birthday where they are, I'll want to use time zones. [[[language=smalltalk | birthday1 birthday2 | birthday1 := (DateAndTime fromString: '2018/01/01T00:00:00+10') asDate. birthday2 := (DateAndTime fromString: '2018/01/01T00:00:00+01') asDate. "Is it person 1's birthday now? (where they live: UTC+10)" birthday1 includes: DateAndTime now. "Do person 1 and person 2 have the same birthday?" birthday1 dmyEquals: birthday2. ]]]
On 21 Nov 2017, at 18:07, Alistair Grant <akgrant0710@gmail.com> wrote:
On 20 November 2017 at 09:16, Sven Van Caekenberghe <sven@stfx.eu> wrote:
We can discuss about this ad infinitum. I think we all agree that there are 2 views (abstract calendar date and concrete time interval/span, which requires a TZ), as well as 2 possible ways to deal with the second case (TZ inside date or as context outside of the date).
Right, I think changing things now will be quite a bit of work.
However there are a couple of things we can do to make life a bit easier:
1. Add a method that facilitates TZ independent comparisons. 2. Add a bit more information in the class comments.
I've named the method #dmyEquals: below, although I don't particularly like it. If anyone has a better idea, please reply.
#equals: #calendarEquals: #equalIgnoreTimezone:
I've also added some proposed text for the class comments.
More comments are always good.
If I don't hear back in a couple of days I'll submit a PR (with automated tests).
Cheers, Alistair
----
dmyEquals: aDate "Perform a time zone independent comparison of the dates, i.e. only compare day, month and year"
^self year = aDate year and: [ self monthIndex = aDate monthIndex and: [ self dayOfMonth = aDate dayOfMonth ] ]
---- Class comment:
Instances of Date are Timespans with duration of 1 day. Their default creation assumes a start of midnight in the local time zone.
!Comparing Dates
We tend to use dates in one of two modes:
- Time zone dependent - Time zone independent
In the first instance, dates are only the same if they are in the same time zone (otherwise they are two different 24 hour periods). This is the default behaviour of Date.
In the second, comparison is only interested in whether the day, month and year are the same.
As an example, take someone's birthday. If I want to know whether we were born on the same day, I will want to compare dates without time zones. If I want to know if it is currently their birthday where they are, I'll want to use time zones.
[[[language=smalltalk | birthday1 birthday2 |
birthday1 := (DateAndTime fromString: '2018/01/01T00:00:00+10') asDate. birthday2 := (DateAndTime fromString: '2018/01/01T00:00:00+01') asDate.
"Is it person 1's birthday now? (where they live: UTC+10)" birthday1 includes: DateAndTime now.
"Do person 1 and person 2 have the same birthday?" birthday1 dmyEquals: birthday2. ]]]
#hasSameDayAs: ----------------- Benoît St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein) From: Alistair Grant <akgrant0710@gmail.com> To: Any question about pharo is welcome <pharo-users@lists.pharo.org> Sent: Tuesday, November 21, 2017 12:07 PM Subject: Re: [Pharo-users] Timespan translateToUTC problematic On 20 November 2017 at 09:16, Sven Van Caekenberghe <sven@stfx.eu> wrote:
We can discuss about this ad infinitum. I think we all agree that there are 2 views (abstract calendar date and concrete time interval/span, which requires a TZ), as well as 2 possible ways to deal with the second case (TZ inside date or as context outside of the date).
Right, I think changing things now will be quite a bit of work. However there are a couple of things we can do to make life a bit easier: 1. Add a method that facilitates TZ independent comparisons. 2. Add a bit more information in the class comments. I've named the method #dmyEquals: below, although I don't particularly like it. If anyone has a better idea, please reply. I've also added some proposed text for the class comments. If I don't hear back in a couple of days I'll submit a PR (with automated tests). Cheers, Alistair ---- dmyEquals: aDate   "Perform a time zone independent comparison of the dates, i.e. only compare day, month and year"   ^self year = aDate year and: [     self monthIndex = aDate monthIndex and:     [ self dayOfMonth = aDate dayOfMonth ] ] ---- Class comment: Instances of Date are Timespans with duration of 1 day. Their default creation assumes a start of midnight in the local time zone. !Comparing Dates We tend to use dates in one of two modes: - Time zone dependent - Time zone independent In the first instance, dates are only the same if they are in the same time zone (otherwise they are two different 24 hour periods). This is the default behaviour of Date. In the second, comparison is only interested in whether the day, month and year are the same. As an example, take someone's birthday. If I want to know whether we were born on the same day, I will want to compare dates without time zones. If I want to know if it is currently their birthday where they are, I'll want to use time zones. [[[language=smalltalk | birthday1 birthday2 | birthday1 := (DateAndTime fromString: '2018/01/01T00:00:00+10') asDate. birthday2 := (DateAndTime fromString: '2018/01/01T00:00:00+01') asDate. "Is it person 1's birthday now? (where they live: UTC+10)" birthday1 includes: DateAndTime now. "Do person 1 and person 2 have the same birthday?" birthday1 dmyEquals: birthday2. ]]]
On 22 November 2017 at 01:07, Alistair Grant <akgrant0710@gmail.com> wrote:
On 20 November 2017 at 09:16, Sven Van Caekenberghe <sven@stfx.eu> wrote:
We can discuss about this ad infinitum. I think we all agree that there are 2 views (abstract calendar date and concrete time interval/span, which requires a TZ), as well as 2 possible ways to deal with the second case (TZ inside date or as context outside of the date).
Right, I think changing things now will be quite a bit of work.
However there are a couple of things we can do to make life a bit easier:
1. Add a method that facilitates TZ independent comparisons. 2. Add a bit more information in the class comments.
I've named the method #dmyEquals: below, although I don't particularly like it. If anyone has a better idea, please reply.
how about #localEquals: i.e. local ==> ignore timezones btw, now we should move to discuss the default date format? https://xkcd.com/1179/ \ ;)-ben== /
On 21 November 2017 at 18:07, Alistair Grant <akgrant0710@gmail.com> wrote:
If I don't hear back in a couple of days I'll submit a PR (with automated tests).
Thanks to Ben, Benoit and Sven for their input. I ended up using #equals: as suggested by Sven. I'd thought of this and had originally rejected it due to it being the same name (when spoken) as #=. But I've also added the other corresponding comparisons, and #equals: fitted in the best. Issue: https://pharo.fogbugz.com/f/cases/20747/ PR: https://github.com/pharo-project/pharo/pull/544 Cheers, Alistair
On 16 November 2017 at 20:23, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
I openend an issue: https://pharo.fogbugz.com/f/cases/20700/translateToUTC-does-not-work-on-Mont...
Thank you for reporting -- Pavel
PR: https://github.com/pharo-project/pharo/pull/545 Cheers, Alistair
2017-11-16 18:36 GMT+01:00 Trussardi Dario Romano <dario.trussardi@tiscali.it>:
Ciao,
i have a Pharo 4.0 image run on macbook with time zone is set to Rome +1 UTC .
When i send the translateToUTC to Date instance it is ok:
Date today > 2017-11-16T00:00:00+01:00
Date today translateToUTC > 2017-11-16T00:00:00+00:00
But for Month instance :
Month month: 6 year: 2015 > 2015-06-01T00:00:00+01:00
( Month month: 6 year: 2015 ) translateToUTC > 2015-06-01T00:00:00+01:00
The same problematic is for Year instance.
Considerations ?
Thanks,
Dario
Thanks you all for this discussion. Last time I used Date and friends I got really frustrated. The navigation between the concept was not really good. I needed for example to manipulate a month in a year: February 2017 (I should check what I did). If I would have time and money I would - create a minimal package private only used by the kernel to load and save image and order changesets. - create a nicer package that we can use for app dev. Stef On Sat, Nov 25, 2017 at 11:54 AM, Alistair Grant <akgrant0710@gmail.com> wrote:
On 16 November 2017 at 20:23, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
I openend an issue: https://pharo.fogbugz.com/f/cases/20700/translateToUTC-does-not-work-on-Mont...
Thank you for reporting -- Pavel
PR: https://github.com/pharo-project/pharo/pull/545
Cheers, Alistair
2017-11-16 18:36 GMT+01:00 Trussardi Dario Romano <dario.trussardi@tiscali.it>:
Ciao,
i have a Pharo 4.0 image run on macbook with time zone is set to Rome +1 UTC .
When i send the translateToUTC to Date instance it is ok:
Date today > 2017-11-16T00:00:00+01:00
Date today translateToUTC > 2017-11-16T00:00:00+00:00
But for Month instance :
Month month: 6 year: 2015 > 2015-06-01T00:00:00+01:00
( Month month: 6 year: 2015 ) translateToUTC > 2015-06-01T00:00:00+01:00
The same problematic is for Year instance.
Considerations ?
Thanks,
Dario
Hmm, in Pharo 7 I see this: TimeZone local. => a LocalTimeZone(LT1:00) { Date today. Date today translateToUTC. Month month: 6 year: 2015. (Month month: 6 year: 2015) translateToUTC } collect: [ :each | each printString -> each start ]. => an Array( '17 November 2017'->2017-11-17T00:00:00+00:00 '17 November 2017'->2017-11-17T00:00:00+00:00 'June 2015'->2015-06-01T00:00:00+00:00 'June 2015'->2015-06-01T00:00:00+00:00) Seems correct to me. And the internal start DateAndTime is already in UTC.
On 16 Nov 2017, at 18:36, Trussardi Dario Romano <dario.trussardi@tiscali.it> wrote:
Ciao,
i have a Pharo 4.0 image run on macbook with time zone is set to Rome +1 UTC .
When i send the translateToUTC to Date instance it is ok:
Date today > 2017-11-16T00:00:00+01:00
Date today translateToUTC > 2017-11-16T00:00:00+00:00
But for Month instance :
Month month: 6 year: 2015 > 2015-06-01T00:00:00+01:00
( Month month: 6 year: 2015 ) translateToUTC > 2015-06-01T00:00:00+01:00
The same problematic is for Year instance.
Considerations ?
Thanks,
Dario
participants (9)
-
Alistair Grant -
Ben Coman -
Benoit St-Jean -
Pavel Krivanek -
Peter Uhnák -
Prof. Andrew P. Black -
Stephane Ducasse -
Sven Van Caekenberghe -
Trussardi Dario Romano