I was very pleased this morning to see that it’s my cakeday (on the forum I administer):
And out of curiosity I went to see who else’s cakeday was nearby. Strangely, though, the anniversaries page seems to be a day in the past:
Could it be because I’m in GMT+8?
That’s what I think.
Given that Discourse localizes the times it shows you everywhere else in the UI, I feel this is still a “bug” and should be fixed.
So there are 24+ different cake day sets? That seems crazy.
That’s one way to look at it I guess. But I’m assuming the users are queried on page load, so there’s really only “one” set at a time.
Here’s a better example. The post you just made shows up for me as “June 8, 2017 12:45 AM”. If I was to fly across the country to California, I’d expect that post to show as “June 7, 2017 9:45 PM”.
…and I just earned the “anniversary” badge this morning. This does feel like a bug to me.
Could it be mitigated by simply changing the timezone of the server to something more applicable for my community? We’re (mainly) in Australia, so processing everything as, say, GMT+8 or GMT+10 would make this all feel less odd.
Not a major issue, of course. 
Since the server doesn’t know a user’s time zone, maybe the easiest fix for this would be to award the badge one day later? For some, that will mean they get it late, but that will probably not be experienced as a bug as much as an early award is.
Another option might be to simply specify in the UI that these times are based on the server’s time zone.
我认为，在一个高度本地化的社区中，应该允许为 Discourse 的“蛋糕日”指定时区。更改服务器时区并不是我们真正能做的事情。
这确实是个棘手的问题，即使我们现在允许用户指定“时区”，我也不确定该如何解决。
假设你在澳大利亚注册了一个论坛，时间是2019 年 1 月 2 日上午 8 点。
根据“蛋糕日”计算，你的 1 周年纪念日将是2010 年 1 月 1 日。
当你在 1 月 2 日上午 8 点访问纪念日页面时，你会看到来自2010 年 1 月 1 日的纪念日，而不是 2 日。
我想我们这里的要求是，使用用户在个人资料中定义的“本地”时区来处理相关事宜。
意思是：
你的 1 周年纪念日应该是2019 年 1 月 1 日，因为你的用户个人资料中的本地时区是澳大利亚。
当你在 2 日访问纪念日页面时，你应该看到 2 日。
目前，我支持一个简单的修复方案：在渲染纪念日页面时，查看当前用户的本地时区，并针对已登录用户的情况，使用该日期而不是 UTC 当前日期。这应该是一个很容易的改动，可能只需要两行代码。
@techAPJ 你能处理一下吗？
我相信 @tgxworld 已经通过以下方式修复了这个问题，以考虑时区偏移：
以及
编辑：我所在的时区是 UTC+5:30，但偏移量为 6 小时，因此我发现对于在 23:30 到 00:00 之间创建账户的用户存在一些边缘情况。正在调查中。
已通过以下方式修复：
