You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Stephane Bailliez (JIRA)" <ji...@apache.org> on 2007/11/22 13:10:43 UTC
[jira] Created: (WICKET-1183) DateTime magic with client timezone
DateTime magic with client timezone
-----------------------------------
Key: WICKET-1183
URL: https://issues.apache.org/jira/browse/WICKET-1183
Project: Wicket
Issue Type: Bug
Components: wicket-datetime
Affects Versions: 1.3.0-rc1
Reporter: Stephane Bailliez
I think it is a bad idea to put this type of code in there, no matter if the default is set to 'dontapplytimezonedifference'
In practice you are either dealing with a well defined timezone or you define it for the user (and you always remind it in the ui), it's not something that you guess from the browser and rely one. A lot of people have totally wrong settings on their computer, you would be surprised also that a lot of people juggling between timezone on business trips do not change their region settings.
It may be cool for one or two specific case, but that's well too magic to be attractive as existing code in the framework and will end up cluttering the framework, therefore I think it is worth removing it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1183) DateTime magic with client timezone
Posted by "Stephane Bailliez (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544894 ]
Stephane Bailliez commented on WICKET-1183:
-------------------------------------------
servers should always be configured as UTC no matter where they are, so this should not even be part of the equation to me. :)
It is just a problem as you said that your timezone was not obvious to your users, it would have been made it clear with a statement such as 'all times are expressed in CET' or something like that and given the possibility to change, it would have probably made a difference .
It's similar to doing the locale straight away based on what the browser says (or the ip) and sticking to that with no way to change, you have to travel in arabic countries or in asia to understand how annoying it is to have that built-in assumption in broken websites.
If I use adsense, I select a timezone for the account and all times will be set with this timezone and it is always clear to me what timezone is being used because all pages remind me what timezone is used.
again it's not a problem of functionalities, it is just I find it to put too much specific code which can lead to a problem in the framework. It is obvious to me when looking at the code it was done to solve a particular US centric problem you have a default short date style the us style and am/pm. Hope you understand what I mean. I think it is just 'too specific' to end up in a framework. (a bit like the border support)
To give another example , if people need to use the datetime field to support 24h format, they have to completely rewrite it entirely as of today to remove the am/pm choice and the validation of time which is limited to 12h, the conversion, etc... You see what I mean. ? You would expect the framework to provide you with a basis to build in, not to have to workaround it. If you publish the api as it is right now, no matter what you'll have to entirely break the api tomorrow to support the 24h format. Thus people previously using your default us/12h will likely be broken, and the people writing the entire 24h support will have duplicated a large chunk of code which is 75% similar to what was existing already.
I probably explained myself very badly, but hope that makes some sort of sense still.
cheers,
> DateTime magic with client timezone
> -----------------------------------
>
> Key: WICKET-1183
> URL: https://issues.apache.org/jira/browse/WICKET-1183
> Project: Wicket
> Issue Type: Bug
> Components: wicket-datetime
> Affects Versions: 1.3.0-rc1
> Reporter: Stephane Bailliez
> Assignee: Eelco Hillenius
> Fix For: 1.3.0-rc2
>
>
> I think it is a bad idea to put this type of code in there, no matter if the default is set to 'dontapplytimezonedifference'
> In practice you are either dealing with a well defined timezone or you define it for the user (and you always remind it in the ui), it's not something that you guess from the browser and rely one. A lot of people have totally wrong settings on their computer, you would be surprised also that a lot of people juggling between timezone on business trips do not change their region settings.
> It may be cool for one or two specific case, but that's well too magic to be attractive as existing code in the framework and will end up cluttering the framework, therefore I think it is worth removing it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1183) DateTime magic with client timezone
Posted by "Stephane Bailliez (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545288 ]
Stephane Bailliez commented on WICKET-1183:
-------------------------------------------
> Code is fixed for WICKET-1150.
yay, thanks for changing to protected
>I don't know what problem you are refering to?
isEnabled() does not trickle down the children node, thus I see that you disable manually the children nodes so that it actually disable the fields.
Tthe datepicker is not displayed at all when the component is disabled though. I haven't put my hands yet on the component rendering logic within wicket so this might be a simple fix.
> about ctor.
I can understand since as a default you have generally 2 to 3 arguments already used, so adding others can create splending combinatorial explosion of the # of constructors and a real mess.
> DateTime magic with client timezone
> -----------------------------------
>
> Key: WICKET-1183
> URL: https://issues.apache.org/jira/browse/WICKET-1183
> Project: Wicket
> Issue Type: Bug
> Components: wicket-datetime
> Affects Versions: 1.3.0-rc1
> Reporter: Stephane Bailliez
> Assignee: Eelco Hillenius
> Fix For: 1.3.0-rc2
>
>
> I think it is a bad idea to put this type of code in there, no matter if the default is set to 'dontapplytimezonedifference'
> In practice you are either dealing with a well defined timezone or you define it for the user (and you always remind it in the ui), it's not something that you guess from the browser and rely one. A lot of people have totally wrong settings on their computer, you would be surprised also that a lot of people juggling between timezone on business trips do not change their region settings.
> It may be cool for one or two specific case, but that's well too magic to be attractive as existing code in the framework and will end up cluttering the framework, therefore I think it is worth removing it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1183) DateTime magic with client timezone
Posted by "Eelco Hillenius (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544899 ]
Eelco Hillenius commented on WICKET-1183:
-----------------------------------------
> servers should always be configured as UTC no matter where they are, so this should not even be part of the equation to me. :)
Sure. But Wicket shouldn't make assumptions on this being a generic framework.
> It is just a problem as you said that your timezone was not obvious to your users, it would have been made it clear with a statement such as 'all times are expressed in CET' or something like that and given the possibility to change, it would have probably made a difference.
> It's similar to doing the locale straight away based on what the browser says (or the ip) and sticking to that with no way to change, you have to travel in arabic countries or in asia to understand how annoying it is to have that built-in assumption in broken websites.
Again, that's you making the choice as an application developer. Why not default to what you think is the best time zone for the user /and/ let the user have the option to change this? If you do this in Wicket's ClientProperties and write code that uses these properties, you'll have it consistent throughout your application.
> again it's not a problem of functionalities, it is just I find it to put too much specific code which can lead to a problem in the framework.
It is optional, so where is the problem? I can understand it if you have problems with defaults, but if you don't think the functionality is good than don't use it. That's why it is implemented optional in the first place.
> It is obvious to me when looking at the code it was done to solve a particular US centric problem you have a default short date style the us style and am/pm. Hope you understand what I mean. I think it is just 'too specific' to end up in a framework. (a bit like the border support)
> To give another example , if people need to use the datetime field to support 24h format, they have to completely rewrite it entirely as of today to remove the am/pm choice and the validation of time which is limited to 12h, the conversion, etc... You see what I mean. ?
Sorry, but I think you're wrong. US/ my problem was the starting point, but it didn't take me long to imagine users scattered all over the world.
The fact that initially am/pm only was supported was because I didn't have time to build in 24 hr support (which I personally prefer). But 24 hour support is implemented now (at least in the last rc), so you should be able to work with that fine. Was there anything that didn't work for you?
> I probably explained myself very badly, but hope that makes some sort of sense still.
Yep. I just don't agree with you :-) 24 hour support is available now, and it is built in in such a way that it doesn't not break the whole world. It depends on the user's locale which one is used, but if you want to pin this to e.g am/pm, that's one override.
> DateTime magic with client timezone
> -----------------------------------
>
> Key: WICKET-1183
> URL: https://issues.apache.org/jira/browse/WICKET-1183
> Project: Wicket
> Issue Type: Bug
> Components: wicket-datetime
> Affects Versions: 1.3.0-rc1
> Reporter: Stephane Bailliez
> Assignee: Eelco Hillenius
> Fix For: 1.3.0-rc2
>
>
> I think it is a bad idea to put this type of code in there, no matter if the default is set to 'dontapplytimezonedifference'
> In practice you are either dealing with a well defined timezone or you define it for the user (and you always remind it in the ui), it's not something that you guess from the browser and rely one. A lot of people have totally wrong settings on their computer, you would be surprised also that a lot of people juggling between timezone on business trips do not change their region settings.
> It may be cool for one or two specific case, but that's well too magic to be attractive as existing code in the framework and will end up cluttering the framework, therefore I think it is worth removing it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1183) DateTime magic with client timezone
Posted by "Eelco Hillenius (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544936 ]
Eelco Hillenius commented on WICKET-1183:
-----------------------------------------
Code is fixed for WICKET-1150.
> and also doing disabled of children components (interesting since I had a similar problem in a component, so I assume you encountered the same one
I don't know what problem you are refering to?
> Also is there any reason to not want to specify the datePattern and the TimeZone optionally in the ctor rather than do inner classes to override the methods ?
The date pattern is typically provided by the bound component; it's not a property.The way DateTimeField can be configured to use a different date pattern is to provide a text field (ITextFormatProvider) that provides the pattern you want. The reason for not providing an overridable method like we do in DatePicker is to ensure that the date picker and date text field are in sync. If that's still not what you want, you can create your custom DateTimeField-like component without too much trouble.
In general, I think having a whole bunch of constructors is poor style. The choice components (abstract class: AbstractChoice) is an example of where we regret having too many. It just makes classes harder to use, and it is kind of contagious as when you want to provide new properties/ options, it often means you have to make that part of a constructor as well to be consistent. Also, we often prefer overridable methods over properties as that saves a bit of memory without making things uglier. You don't have to use anonymous classes btw. If you plan to reuse something more than once, just make it a new top level class.
> I find it pretty common and it's really the first thing I would expect to have as it is a common idiom.
The common case is that it just works without having to specify either the timezone or the date pattern directly. The time zone is provided as a client property, and the short date pattern (the default) works best with popups and text fields.
> DateTime magic with client timezone
> -----------------------------------
>
> Key: WICKET-1183
> URL: https://issues.apache.org/jira/browse/WICKET-1183
> Project: Wicket
> Issue Type: Bug
> Components: wicket-datetime
> Affects Versions: 1.3.0-rc1
> Reporter: Stephane Bailliez
> Assignee: Eelco Hillenius
> Fix For: 1.3.0-rc2
>
>
> I think it is a bad idea to put this type of code in there, no matter if the default is set to 'dontapplytimezonedifference'
> In practice you are either dealing with a well defined timezone or you define it for the user (and you always remind it in the ui), it's not something that you guess from the browser and rely one. A lot of people have totally wrong settings on their computer, you would be surprised also that a lot of people juggling between timezone on business trips do not change their region settings.
> It may be cool for one or two specific case, but that's well too magic to be attractive as existing code in the framework and will end up cluttering the framework, therefore I think it is worth removing it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1183) DateTime magic with client timezone
Posted by "Eelco Hillenius (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eelco Hillenius resolved WICKET-1183.
-------------------------------------
Resolution: Won't Fix
Fix Version/s: 1.3.0-rc2
Assignee: Eelco Hillenius
I disagree. I never thought about this thing much when I lived in The Netherlands, mainly building Dutch systems for one time zone. But now I'm living and working in the US, with servers placed in NYC and clients all over the country from different timezones. We kept on getting users who didn't understand that times they saw was the time of where the servers are located, so it was obvious to me we needed a generic translation for it.
And think of it: when you open gmail or any other web email client, you see those times converted to your time zone (and you can test that by changing the time zone and look at your email again). It's something that is completely natural, whereas displaying for one particular time zone is something programmers might understand, but the rest of the world probably don't. It also doesn't make sense when you a cluster running over multiple time zones.
So... I actually think this is a better default. Yes, users can 'mess up' their time zones, but if they do, they'll have plenty of occasions where they'll be hurt. I'm closing this as won't fix because I think the functionality is great, and it is optionally anyway, so you can ignore it if you want.
> DateTime magic with client timezone
> -----------------------------------
>
> Key: WICKET-1183
> URL: https://issues.apache.org/jira/browse/WICKET-1183
> Project: Wicket
> Issue Type: Bug
> Components: wicket-datetime
> Affects Versions: 1.3.0-rc1
> Reporter: Stephane Bailliez
> Assignee: Eelco Hillenius
> Fix For: 1.3.0-rc2
>
>
> I think it is a bad idea to put this type of code in there, no matter if the default is set to 'dontapplytimezonedifference'
> In practice you are either dealing with a well defined timezone or you define it for the user (and you always remind it in the ui), it's not something that you guess from the browser and rely one. A lot of people have totally wrong settings on their computer, you would be surprised also that a lot of people juggling between timezone on business trips do not change their region settings.
> It may be cool for one or two specific case, but that's well too magic to be attractive as existing code in the framework and will end up cluttering the framework, therefore I think it is worth removing it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1183) DateTime magic with client timezone
Posted by "Frank Bille Jensen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Frank Bille Jensen updated WICKET-1183:
---------------------------------------
Fix Version/s: (was: 1.3.0-rc2)
> DateTime magic with client timezone
> -----------------------------------
>
> Key: WICKET-1183
> URL: https://issues.apache.org/jira/browse/WICKET-1183
> Project: Wicket
> Issue Type: Bug
> Components: wicket-datetime
> Affects Versions: 1.3.0-rc1
> Reporter: Stephane Bailliez
> Assignee: Eelco Hillenius
>
> I think it is a bad idea to put this type of code in there, no matter if the default is set to 'dontapplytimezonedifference'
> In practice you are either dealing with a well defined timezone or you define it for the user (and you always remind it in the ui), it's not something that you guess from the browser and rely one. A lot of people have totally wrong settings on their computer, you would be surprised also that a lot of people juggling between timezone on business trips do not change their region settings.
> It may be cool for one or two specific case, but that's well too magic to be attractive as existing code in the framework and will end up cluttering the framework, therefore I think it is worth removing it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1183) DateTime magic with client timezone
Posted by "Stephane Bailliez (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544903 ]
Stephane Bailliez commented on WICKET-1183:
-------------------------------------------
>But 24 hour support is implemented now (at least in the last rc), so you should be able to work with that fine. Was there anything that didn't work for you?
mmm...ok not sure what rc you're talking about, but unless there is a problem with the rc1 release only the code in svn trunk right now has 24h and also doing disabled of children components (interesting since I had a similar problem in a component, so I assume you encountered the same one ?)
will check the code deeper, but I do have already the following question after a quick glance:
- how do you let people specify the timezone ? the method is private, I don't see anyway other than rewrite convertInput and onBeforeRender (it's late here, so I might be blind)
Also is there any reason to not want to specify the datePattern and the TimeZone optionally in the ctor rather than do inner classes to override the methods ? I find it pretty common and it's really the first thing I would expect to have as it is a common idiom.
cheers
> DateTime magic with client timezone
> -----------------------------------
>
> Key: WICKET-1183
> URL: https://issues.apache.org/jira/browse/WICKET-1183
> Project: Wicket
> Issue Type: Bug
> Components: wicket-datetime
> Affects Versions: 1.3.0-rc1
> Reporter: Stephane Bailliez
> Assignee: Eelco Hillenius
> Fix For: 1.3.0-rc2
>
>
> I think it is a bad idea to put this type of code in there, no matter if the default is set to 'dontapplytimezonedifference'
> In practice you are either dealing with a well defined timezone or you define it for the user (and you always remind it in the ui), it's not something that you guess from the browser and rely one. A lot of people have totally wrong settings on their computer, you would be surprised also that a lot of people juggling between timezone on business trips do not change their region settings.
> It may be cool for one or two specific case, but that's well too magic to be attractive as existing code in the framework and will end up cluttering the framework, therefore I think it is worth removing it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.