Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support date timezone #157

Open
gyscos opened this issue Apr 6, 2017 · 9 comments

Comments

@gyscos
Copy link

commented Apr 6, 2017

Currently, formatting a timestamp with the date filter prints the time on the UTC timezone.
It would be useful to be able to specify the desired timezone, or to default on the local one.

@Keats

This comment has been minimized.

Copy link
Owner

commented Apr 7, 2017

It doesn't really prints the time on the UTC timezone, it's just some leftover code that need to be cleaned up: it takes the date and just says yup this is UTC just format it so. If you are using time zone in the format it will output the wrong tz though.
For the case of rfc3339 dates, it should be handled separately looking at the code since, as we have a timezone, there's no need to convert it to a Naive date. I've created an issue for that.

For the time zone in the filter, I'm not entirely sure yet how to do that. Looking at django, they have the following filters: https://docs.djangoproject.com/en/1.11/topics/i18n/timezones/#std:templatefilter-localtime which returns datetime. Unless Tera uses its own serialization instead of serde_json, we don't have a concept of datetime objects so that approach doesn't really work.
It could work for rfc3339 dates as we have a timezone but not for timestamps or YYYY-MM-DD (where it doesn't apply at all anyway).

I think for now if you want to deal with time zones it's better to do it in your code where you have date DateTime objects. It would be a bit weird for the filter to have options that work only on 1 type of input out of 3 :/

@gyscos

This comment has been minimized.

Copy link
Author

commented Apr 7, 2017

I think there are two sides to the process:

  • Input: parse the date. The result is an actual point in time, independent of time zone (for instance a timestamp).
    • If the input is a timestamp, no timezone is needed. This was my situation.
    • If the input specify a timezone (either through a date object or a given in a string), keep it
    • If the date is given without a time zone, I suppose assume local timezone
  • Output: format the date, as seen in a timezone.
    • If the input specified a timezone, we could use the same one.
    • Since timestamp (without a timezone) is a valid input, we need to either assume local time, or find a way to specify the timezone separately, maybe as another parameter to the date filter.
@Keats

This comment has been minimized.

Copy link
Owner

commented Apr 11, 2017

The part where it overwrites timezone is fixed in #161

I'm still a bit unsure of setting a timezone from the filter, for me the filter is purely formatting. I'm not against it though (there seems to be precedent in https://twig.sensiolabs.org/doc/2.x/filters/date.html) but that seems like a big chunk of work, ie mapping timezones like "Europe/Paris" to a timezone. It looks like https://github.com/djzin/chrono-tz could be used but I don't know if it's mature as a library.

@gyscos

This comment has been minimized.

Copy link
Author

commented Apr 11, 2017

The problem is when input is a timestamp, not a date object. How do i at least use local timezone instead of UTC?

@Keats

This comment has been minimized.

Copy link
Owner

commented Apr 20, 2017

That case would fall under the umbrella of chrono-tz (or similar project), assuming the timestamps are in UTC. If the timestamps are not in UTC then it's another mess.

Either way if we add more date handling, Tera will need to know the local timezone and the filter would use it so that would be a breaking change for 0.10 I guess?

@gyscos

This comment has been minimized.

Copy link
Author

commented Apr 21, 2017

Maybe a full timezone-parsing is not required. My main concern is to use local time - this is the most common thing to do, and is probably what most systems default to.

When printing date from a simple unix-time timestamp (which is very common, as such values are stored everywhere), I don't know of a situation where a user would want to print the UTC time rather than the local time.

@Keats

This comment has been minimized.

Copy link
Owner

commented Apr 21, 2017

When printing date from a simple unix-time timestamp (which is very common, as such values are stored everywhere), I don't know of a situation where a user would want to print the UTC time rather than the local time.

For example when you want to print a UTC timestamp on the end user time zone and not the server.

@gyscos

This comment has been minimized.

Copy link
Author

commented Apr 21, 2017

Timestamps aren't "UTC", they're timezone-agnostic.
I agree that using the user's timezone rather than the local one is a use-case, but the user timezone being UTC is just a special case of it. Fully configurable timezone is of course a cool feature, but just "UTC" sounds much less common.

@Keats

This comment has been minimized.

Copy link
Owner

commented Apr 26, 2017

Timestamps aren't "UTC", they're timezone-agnostic.

Unix timestamps are always UTC and I expect they are the most kind of timestamps used.

but just "UTC" sounds much less common.

That's how we do it at least. And display in the user timezone using javascript though.

I don't think I'll change the filter unless many people think it is confusing. It is pretty easy to add your own filter after all

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.