K
Kasper Tidemann
[Note: parts of this message were removed to make it a legal post.]
Hi ruby-lang list,
Thank you all for reading this mail.
I am struggling to handle week numbers properly on a web platform made in
Ruby that is used across several countries. I have googled this for days
trying to find a solution, but I have not had any success whatsoever so far.
The problem is the following:
------- DENMARK:
1) Say we are using the system in Denmark and we want to know the week
number of the date 2009-12-31.
2) Denmark follows the ISO 8601 standard for calendar handling, and the
server running the system is initialized using the Europe/Copenhagen time
zone.
3) Executing Date.civil(2009, 12, 31).cweek returns "53", which is the
correct answer, since December 31st 2009 is part of week 53 in Denmark (and
the rest of Europe, pretty much).
------- USA:
1) Now we are using the system in USA, but still communicating with the same
server here in Denmark, the UI itself just speaks English.
2) When I execute Date.civil(2009, 12, 31).cweek, it still - obviously -
returns "53". But in the case of USA, this is wrong, since December 31st
2009 would be week 52 according to the US Standard.
-------
Now, I have tried to use TZInfo for Ruby, doing a
Time.zone.parse("2009-12-31").strftime("%W") to get the week number of
December 31st 2009 - with weeks beginning on Monday (ISO 8601). This returns
52, which is WRONG according to European standards.
However, executing Time.zone.parse("2009-12-31").strftime("%U") to get the
week number of December 31st 2009 - with weeks beginning on Sunday (US
Standard) - returns 52. Which is right.
So, I have Date.civil that tells me one thing - 53 - and Time.zone that
tells me another - 52. Either is wrong in one of the cases.
Do you guys have any ideas regarding handling the week numbers correctly
according to the country of the user? Is there a way to tell Date.civil() to
follow a specific standard, or does it just inherit from the machine
settings no matter what? What can I do to fix this?
Thank you for your help.
All the best,
Kasper Tidemann
(e-mail address removed)
Hi ruby-lang list,
Thank you all for reading this mail.
I am struggling to handle week numbers properly on a web platform made in
Ruby that is used across several countries. I have googled this for days
trying to find a solution, but I have not had any success whatsoever so far.
The problem is the following:
------- DENMARK:
1) Say we are using the system in Denmark and we want to know the week
number of the date 2009-12-31.
2) Denmark follows the ISO 8601 standard for calendar handling, and the
server running the system is initialized using the Europe/Copenhagen time
zone.
3) Executing Date.civil(2009, 12, 31).cweek returns "53", which is the
correct answer, since December 31st 2009 is part of week 53 in Denmark (and
the rest of Europe, pretty much).
------- USA:
1) Now we are using the system in USA, but still communicating with the same
server here in Denmark, the UI itself just speaks English.
2) When I execute Date.civil(2009, 12, 31).cweek, it still - obviously -
returns "53". But in the case of USA, this is wrong, since December 31st
2009 would be week 52 according to the US Standard.
-------
Now, I have tried to use TZInfo for Ruby, doing a
Time.zone.parse("2009-12-31").strftime("%W") to get the week number of
December 31st 2009 - with weeks beginning on Monday (ISO 8601). This returns
52, which is WRONG according to European standards.
However, executing Time.zone.parse("2009-12-31").strftime("%U") to get the
week number of December 31st 2009 - with weeks beginning on Sunday (US
Standard) - returns 52. Which is right.
So, I have Date.civil that tells me one thing - 53 - and Time.zone that
tells me another - 52. Either is wrong in one of the cases.
Do you guys have any ideas regarding handling the week numbers correctly
according to the country of the user? Is there a way to tell Date.civil() to
follow a specific standard, or does it just inherit from the machine
settings no matter what? What can I do to fix this?
Thank you for your help.
All the best,
Kasper Tidemann
(e-mail address removed)